[Development] Nominating Volker Hilsheimer as maintainer of Qt Speech

[Frederik Gladhorn]

Hello :)

I've lately not had time to contribute to Qt (personal life keeping me
busy).
Since Volker and others did a great job porting Qt Speech to Qt 6, they
know the code better than me by this time. I'd like to step down as
maintainer and allow those who actually contribute to take over.

Hereby I nominate Volker as maintainer (he's agreed privately already).

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

[Development] Nominating Jan Arve Sæther as maintainer for accessibility

[Frederik Gladhorn]

Hi all,

I'd like to pass on the torch and step down as maintainer for accessibility in 
Qt.
I haven't been very active in the area lately. Jan Arve has been involved in 
most improvements and been much more active in reviews and improving our 
offering. I'd like to nominate him as new maintainer.

I'm currently also listed as Qt Speech maintainer, I'm unsure how much time 
I'll spend on it in the future, so if someone wants to take over, I'd be happy 
to give up that maintainer role as well.

Greetings,
Frederik

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

Re: [Development] clang-format

[Frederik Gladhorn]

Hi Mitch,

thanks for trying!

On mandag 14. oktober 2019 14:51:41 CEST Mitch Curtis wrote:
> As a side note, I installed it on Ubuntu 18.04.3 with:
> 
> sudo apt-get install clang-format
> 
> but there was no git-clang-format binary, even though
> https://packages.ubuntu.com/search?searchon=contents=git-clang-for
> mat=exactfilename=disco=any said there should be, so I just
> made a symbolic link to it:
 
> sudo ln -s /usr/bin/git-clang-format-6.0 /usr/bin/git-clang-format
> 
> Would be great to know if there's a proper way to do this that I'm missing.

git-clang-format should be shipped with clang-format, but of course each linux 
distro does it's own thing, potentially. On (K)ubuntu 19.04 I have:
dpkg -S /usr/bin/git-clang-format
clang-format: /usr/bin/git-clang-format

So there it simply ships with clang-format and things work out of the box.
On macOS it also seems to work after getting clang from homebrew.
And on Windows it may just be working... fingers crossed.

I hope it turns into something useful :)

Cheers,
Frederik


> 
> 
> > 
> > 
> > ___
> > 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] clang-format

[Frederik Gladhorn]

Hi,

after just a bit over a year, we have a hint of progress on the state of using 
clang-format.

If you use qt5.git, you'll get the git hook for it set up, to automatically 
run clang-format on the lines you changed.
To benefit today, get the dev branch of qt5 and run init-repository -f --force-
hooks.
The commit hook runs and shows a diff of what should be changed, but doesn't 
add anything, so your changes should be safe from unwanted reformatting no 
matter what.
If you think the changes make sense, just run "git clang-format" and all the 
things you have added to the staging area will be reformatted.

git add myfile # stage a file
git commit # try to commit, clang-format thinks you need to reformat
git clang-format # apply the reformatting to the index
git diff # see what clang-format did

The hook script which is probably far from optimal (written in sh) is found in 
qt/qtrepotools. You can also just link https://code.qt.io/cgit/qt/
qtrepotools.git/tree/git-hooks/clang-format-pre-commit as pre-commit into your 
.git/hooks directory and you get to enjoy it.

I bet we'll have some issues and it's not quite perfect, but hey, small 
progress.

Enjoy re-formatting and feel relaxed about it too ;)

Cheers,
Frederik



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

Re: [Development] HEADS-UP: Branching from '5.13' to '5.13.2' started

[Frederik Gladhorn]

On fredag 4. oktober 2019 06:33:33 CEST Jani Heikkinen wrote:
> Hi all,
> 
> We have now soft branched '5.13.2' from '5.13'. Final downmerge from '5.13'
> to '5.13.2' will happen Fri 11th October. So please start using '5.13.2'
> for new changes targeted to Qt 5.13.2 release.

Even more, feel free to move changes, everything aiming for 5.13.2 should now 
actually target it.
We'll do the final merge on Thursday or latest Friday.
The great thing is that you don't have to rely on that but can rather target 
the right branch from this second on :-)

Happy fixing!
Frederik

> 
> Target is to get Qt 5.13.2 out at week 42 (17th October) so please make sure
> all release blockers are visible in blocker list
> (https://bugreports.qt.io/issues/?filter=21537) & all issues from blocker
> list will be fixed immediately.
> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

Re: [Development] Nominating Vitaly Fanaskov as Approver

[Frederik Gladhorn]

+1 from me :)

Cheers,
Frederik

On onsdag 2. oktober 2019 13:22:33 CEST Shawn Rutledge wrote:
> Hi all,
> 
> I would like to nominate Vitaly Fanaskov as approver for the Qt Project.
> Vitaly joined the Qt Quick and Widgets team about a year ago.  He has been
> fixing bugs in widgets and Qt Quick, making it easier to use and customize
> color palettes in Qt Quick, working on the speech module, working on
> KUserFeedback (which we will use for telemetry in Creator), teaching us how
> to use some modern C++ features that some of us didn’t know about before,
> etc.
 I trust that he will follow Qt guidelines and will use the approver
> rights responsibly. 
> Here is his list of changes:
> https://codereview.qt-project.org/q/owner:
> 
> vitaly.fanaskov %40qt.io>%2540qt.io
 
> and reviews:
> https://codereview.qt-project.org/q/reviewer:vitaly.fanaskov%2540qt.io ://codereview.qt-project.org/q/reviewer:kirill.burtsev%40qt.io>
 
> Disclaimer: we are working in the same company, same team and same room.
> 




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

Re: [Development] Gerrit update

[Frederik Gladhorn]

On tirsdag 1. oktober 2019 08:10:20 CEST Jukka Jokiniva wrote:
> Hi,
> 
> You supposed to press the "Stage" button like before.
> The greyed Submit button is kind of technically ok,  but creates confusion
> because it was previously hidden.
 
> I created a task to Jira to hide it,
> https://bugreports.qt.io/browse/QTQAINFRA-3245

The fix should be deployed now, you will have to reload the page (and maybe 
drop caches(?)).

Sorry for the confusion this caused.

Cheers,
Frederik

 
> --Jukka
> 
> 
> From: Development  on behalf of
> Bogdan Vatra via Development 
 Sent: Tuesday,
> October 1, 2019 7:53 AM
> To: development@qt-project.org
> Subject: Re: [Development] Gerrit update
> 
> Hi,
> 
>   Since yesterday I can't submit any of my patches. The submit "button"
> is
 gay, e.g. https://codereview.qt-project.org/c/qt/qtbase/+/273675 
> Am I doing something wrong?
> 
> Cheers,
> BogDan.
> 
> În ziua de luni, 30 septembrie 2019, la 09:40:36 EEST, Heikki Halmet a
> scris:
> > Hi,
> >
> >
> >
> > Coin fixed and integrations should be work now.
> > Thanks for your patience!
> >
> >
> >
> >
> > Br
> > Heikki
> >
> >
> >
> > -Original Message-
> > From: Development  On Behalf Of
> > Heikki
> > Halmet
> 
>  Sent: maanantai 30. syyskuuta 2019 9.20
> 
> > To: Jukka Jokiniva ; Qt Project Development
> > Mailing-List 
> 
>  Subject: Re: [Development]
> 
> > Gerrit update - problem with integrations
> > Hi,
> >
> >
> >
> > We have problem in Coin with the newer Gerrit version. It means that
> > currently integrations won't work. We are fixing the issue with
> > highest
> > priority.
> 
> 
> 
> >
> >
> > Br
> > Heikki
> >
> >
> >
> > -Original Message-
> > From: Development  On Behalf Of
> > Jukka
> > Jokiniva
> 
>  Sent: maanantai 30. syyskuuta 2019 8.52
> 
> > To: Qt Project Development Mailing-List 
> > Subject: [Development] Gerrit is back online
> >
> >
> >
> >
> > Gerrit is back online,
> >
> >
> >
> > Main changes to the functionality are:
> > 
> >* Confirmation dialog for Stage button has been removed.
> >* Each staging attempt doesn't not generate new patch set for the
> >change.
> > 
> > New patch set is added only after successful integration.
> 
> 
> 
> >  --Jukka
> >
> >
> >
> >
> >
> > On 30/09/2019, 7.57, "Development on behalf of Jukka Jokiniva"
> >  > jukka.jokin...@qt.io>
> > wrote:
> 
> 
> 
> >
> >
> > Hi,
> >
> >
> >
> > Gerrit 3.0.2 upgrade starts in 5 minutes. The
> > codereview.qt-project.org
> > 
> > will be offline for about  20 - 30 mins.
> 
> 
> 
> > --Jukka
> >
> >
> >
> >
> >
> > On 23/09/2019, 16.50, "Development on behalf of Frederik
> > Gladhorn"
> > 
> >  > frederik.gladh...@qt.io>
> > wrote:
> 
> 
> 
> > Hi all,
> >
> >
> >
> > I hope this is a complete no-event, but we'd like to give you
> > a
> > 
> > heads-up, in
> 
>  case something unexpected comes up. We Gerrit admins are
> 
> > currently working towards moving us to Gerrit 3.0.2.
> >
> >
> >
> > The plan is to upgrade on Monday next week, the 30th of
> > September.
> > There are no huge improvements in Gerrit itself, it's a
> > cleanup
> > 
> > release
> 
>  mostly, getting rid of the old database handling moving
> 
> > completely to note-db.
> > 
> > We don't expect major issues, the testserver upgrade takes
> > around
> > 
> > five minutes,
> 
>  so there will be a short down-time, but otherwise there
> 
> > sho

[Development] Gerrit upgrade on Monday

[Frederik Gladhorn]

Hi all,

I hope this is a complete no-event, but we'd like to give you a heads-up, in 
case something unexpected comes up. We Gerrit admins are currently working 
towards moving us to Gerrit 3.0.2.

The plan is to upgrade on Monday next week, the 30th of September.
There are no huge improvements in Gerrit itself, it's a cleanup release 
mostly, getting rid of the old database handling moving completely to note-db.

We don't expect major issues, the testserver upgrade takes around five minutes, 
so there will be a short down-time, but otherwise there shouldn't be any real 
interruptions.
We'll be testing in the meantime and may still postpone the upgrade, in case 
any blockers are found.

Cheers,
Frederik



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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Frederik Gladhorn]

On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
> Albert Astals Cid (16 September 2019 11:33) wrote:
> > If i do
> > 
> >   git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
> > 
> > I get branch 5.12
> > 
> > Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> > sense to default to branch 5.13?
> 
> We have a history of setting a release branch (stable, I think; perhaps
> LTS) as the default branch in our repositories.  This means that anyone
> who mirrors our repositories gets that as their default branch (unless /
> until they update it).  I don't see this as a good choice: getting dev
> on the branches that have it would make more sense.
> 
> IIUC, the rationale for the present practice is that we want to make it
> easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
> having fixes sent to us on dev a bit more often (and other changes, that
> *do* belong on dev, being sent first to another branch would surely
> happen less often); reviewers can surely help the contributor get it
> onto the right branch, if there's a good reason why dev isn't good
> enough.
> 
> ... now, where have I met this discussion recently ?
> I'm quite sure I have, but can't remember where ...

I also had a chat about this recently and the Gerrit admins in general don't 
really fell like constantly changing the default branch, so I'd be much in 
favor of just moving all default branches to dev.

In my opinion we should mostly care about the dev branch, since that's where 
all future development needs to happen. Moving changes back into older 
releases can of course be important, but that's not what most people should 
have to worry about.

Cheers,
Frederik


> 
>   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 David Edmundson as approver

[Frederik Gladhorn]

+1 from me as well, also from working on KDE things with David. And he's been 
upstreaming stuff - yay :)

Cheers,
Frederik


On fredag 23. august 2019 14:15:59 CEST Johan Helsing wrote:
> Hi all,
> 
> I'd like to nominate David Edmundson as approver for the Qt Project. David
> started contributing to Qt in 2013 and has been active contributing and
> reviewing patches in QtWayland for the past two years. His patches and
> reviews have a very high quality and I trust he will use his rights
> responsibly.
> 
> Here is his list of contributions:
> https://codereview.qt-project.org/q/owner:davidedmundson%2540kde.org
> 
> And reviews:
> https://codereview.qt-project.org/q/reviewer:davidedmundson%2540kde.org
> 
> Best regards,
> Johan Helsing




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

Re: [Development] Moving to Gerrit 2.16.9

[Frederik Gladhorn]

On mandag 1. juli 2019 21:23:35 CEST André Hartmann wrote:
> Hi all,
> 
> I'm not sure if it's related to the gravatars, but Gerrit became
> horrible slow here (this is on a 2MBit DSL line). It's almost unuseable.
> 
> Has someone else experienced the same?

Yes, it slowed to a crawl yesterday, we're trying to find out why, even though 
that's always a bit tricky post mortem. We do have some records of the 
resource usage and the logs, but the logs seem rather innocent from what I 
could tell yesterday.

Cheers,
Frederik

> 
> Regards,
> André
> 
> Am 01.07.19 um 19:57 schrieb André Pönitz:
> > On Mon, Jul 01, 2019 at 02:43:43PM +, Frederik Gladhorn wrote:
> >>>> and I'll give Gravatar a spin:
> >>>> https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-grav
> >>>> ata
> >>>> r
> >> 
> >> It's there, enjoy and put your avatar up at https://gravatar.com .
> > 
> > I know it's a bit late and it won't change anything anyway.
> > 
> > Still: Was there an explanation of the benefits of using gravatar
> > somewhere, also perhaps in the light of discussions like
> > 
> > https://meta.stackexchange.com/questions/4553/can-we-use-non-gravatar-avat
> > ars/5658#5658
> > 
> > ?
> > 
> > Andre'
> > ___
> > 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] Deprecation/removal model going into Qt 6

[Frederik Gladhorn]

On søndag 2. juni 2019 11:50:35 CEST Volker Hilsheimer wrote:
> > On 1 Jun 2019, at 16:12, Alberto Mardegan 
> > wrote:
 
> > On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
> > 
> >> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
> >> three years maintenance. We are not expecting lots of people to jump
> >> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when
> >> an API was marked as deprecated makes perhaps not that much
> >> difference “in real time”.
> > 
> > 
> > Three years is not a lot of time when moving between major releases. It
> > would be nice if the last LTS release in a major release series were
> > supported for a longer time (5 years?).
> > 
> > Ciao,
> > 
> >  Alberto
> 
> 
> 
> How long did it take y’all to move from Qt 4.x to Qt 5.x?
> 
> The move from Qt 2 to Qt 3, and from Qt 3 to Qt 4, is brought up as examples
> of bad experiences (but then let’s also consider how terrible Qt would be
> today if we would still have to drag Qt 2 or Qt 3 concepts around with us).
> But if the goal for Qt 6 is to be rather comparable to the Qt 4 to Qt 5,
> how bad would it be?
 
> Of course, milage will vary depending on the nature and size of your
> codebase, and I’m sure my colleagues in The Qt Company sales would be happy
> to discuss support options, when the time comes.
 

I don't think there's a conflict here: If we had frequent major version bumps, 
I'd still expect some of these (one version of each major)? To be the LTS 
version for that major, which will be supported for quite a long time.

We can give people ample time to move forward, while still creating new 
majors.

And I think the smaller the time delta between major releases, the easier it 
is to move forward.

Cheers,
Frederik


> Cheers,
> 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] Moving to Gerrit 2.16.9

[Frederik Gladhorn]

And we're on 2.16.9, which brings no huge improvements as far as I can tell.
But it's great to gather some experience and more and more automate the 
deployment of new versions. Enjoy!

On torsdag 27. juni 2019 16:53:26 CEST Tor Arne Vestbø wrote:
> > On 27 Jun 2019, at 16:10, Frederik Gladhorn 
> > wrote:
> > 
> > On a related note, now that things are generally working with the new
> > Gerrit, I was wondering if we want to consider plugins. There is one to
> > add reviewers based on git blame
> > https://gerrit-review.googlesource.com/admin/repos/plugins/reviewers-by-bl
> > ame
> YES

Hum, I didn't manage to get this one to do anything in our test instance, so 
it's skipped for now, I hope we'll find a way to get it to work and maybe start 
using it. I personally hope it would be a good addition, but would propose a 
test period, if there are many people complaining, we could just get rid of it 
again. Anyhow, this pends figuring out how to get it to work.

> 
> > and I'll give Gravatar a spin:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravata
> > r

It's there, enjoy and put your avatar up at https://gravatar.com .

> 
> YES
> 
> > We should also consider the various webhooks plugins. Comments
> > appreciated.
> 
> YES, the core webhook one

Done, we have the webhooks installed now, just not configured in any way yet.

Cheers,
Frederik


> 
> Tor Arne




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

Re: [Development] Moving to Gerrit 2.16.9

[Frederik Gladhorn]

On fredag 28. juni 2019 17:29:29 CEST Mutz, Marc wrote:
> On 2019-06-27 16:10, Frederik Gladhorn wrote:
> [...]
> 
> > On a related note, now that things are generally working with the new
> > Gerrit,
> > I was wondering if we want to consider plugins. There is one to add
> > reviewers
> > based on git blame
> > https://gerrit-review.googlesource.com/admin/repos/plugins/reviewers-by-bl
> > ame and I'll give Gravatar a spin:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravata
> > r
> > 
> > We should also consider the various webhooks plugins. Comments
> > appreciated.
> 
> I don't know whether there's a plugin for that, but a feature that would
> really benefit a lot of Qt devs would be if Gerrit would understand
> whether the Merge Conflict is due to a prerequisite commit not having
> been merged, yet, or whether there's really a conflicting commit merged.
> It kind of knows already, since it shows which other commits conflict
> with the current one, if any, but it still shows Merge Conflict for
> missing prerequisite commits. It would be totally cool if instead of
> Merge Conflict, it would show Prerequisite Missing (e.g.).
> 
> And then, going into dream mode, if one could add a prerequisite
> manually, across modules, so that a, say, qtdeclarative change could
> track a qtbase one and show Prerequisite Missing until the qtbase commit
> has been merged _and integrated_ in qt5.
> 
> Don't know how hard this would be to implement, or if it's possible at
> all.

I agree that merge commits are confusing. In general I'd say the dependency 
tracking is not always super clear in the new UI.

The merge conflict detection is part of Gerrit core, there are no plugins that 
go so deep as far as I know. Improving that should clearly be done upstream, 
in Gerrit core.

If anyone wants to contribute, this kind of improvement should be welcome.

Cheers,
Frederik

> 
> Thanks,
> Marc




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

[Development] Moving to Gerrit 2.16.9

[Frederik Gladhorn]

Hi,

Just to keep the ball rolling, we prepared the upgrade to move from Gerrit 
2.16.7 to 2.16.9. I don't expect any real changes, but it's a good exercise 
for us to stay up to date and see if the scripting of the upgrade works.
The only real challenge was upgrading Bazel, since every Gerrit version seems 
to only compile with one exact Bazel version (roughly).

So far it seems to work nicely for me, running the script which stops gerrit, 
pushes the new release and restarts it takes around two minutes, so there 
won't be any significant downtime this time around.

Assuming there are no big concerns I'll just do the upgrade tomorrow, on the 
test instance it works without problems.

On a related note, now that things are generally working with the new Gerrit, 
I was wondering if we want to consider plugins. There is one to add reviewers 
based on git blame
https://gerrit-review.googlesource.com/admin/repos/plugins/reviewers-by-blame
and I'll give Gravatar a spin:
https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravatar

We should also consider the various webhooks plugins. Comments appreciated.

Cheers,
Frederik



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

[Development] Nominating Jukka Jokiniva as approver

[Frederik Gladhorn]

Hi all,

I'd like to nominate Jukka Jokiniva as approver for the Qt Project. Jukka has 
been less visible in the past, since he was mostly involved with 
infrastructure before, but he made the Gerrit upgrade happen and he is now 
active as release manager, next to Jani.
His focus is on the embedded and automotive releases.

Here is his list of contributions:
https://codereview.qt-project.org/q/owner:jukka.jokiniva%2540qt.io
And reviews:
https://codereview.qt-project.org/q/reviewer:jukka.jokiniva%2540qt.io

Cheers,
Frederik



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

Re: [Development] How to port from Q_FOREACH to range-based for

[Frederik Gladhorn]

On tirsdag 11. juni 2019 09:48:00 CEST Lars Knoll wrote:
> > On 11 Jun 2019, at 09:35, Olivier Goffart  wrote:
> > 
> > On 11.06.19 09:17, Lars Knoll wrote:
> > 
> >> So, is removing it worth all the hassle to us and our users? Q_FOREACH is
> >> a macro and it doesn’t really cost us anything to keep it around. Yes,
> >> it has issues with non Qt containers and I wouldn’t recommend it for any
> >> new code. But maybe we could simply fix that part, but making Q_FOREACH
> >> emit a compiler warning if used on a container that’s not implicitly
> >> shared?
> 
> > 
> > +1
> > Although we should probably still discourage its usage in the
> > documentation.
 
> > Regarding the compiler warning:
> > 
> >  https://codereview.qt-project.org/c/qt/qtbase/+/244010
> > 
> > 
> 
> 
> Nice. So doesn’t this solve most of the issues we have with Q_FOREACH (maybe
> with the exception that some people find macros ugly)?

Yes, I'd also be happy about changes to the docs, let's really not encourage 
new uses of foreach. But I think we'd do ourselves and especially our users a 
disfavor by deprecating it.

I have seen enough bugs introduced by people fixing deprecation warnings 
blindly, and there seem to be so many issues when it comes to foreach that I 
think it's simply not worth it.

Frederik

(I hope q_foreach continues its long career in the shade, relaxing and slowly 
fading from public memory...)

 
> Cheers,
> Lars
> 
> ___
> 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 is back / email template changed

[Frederik Gladhorn]

On tirsdag 28. mai 2019 16:26:18 CEST Florian Bruhin wrote:
> On Tue, May 28, 2019 at 02:17:19PM +0000, Frederik Gladhorn wrote:
> > If someone has other ideas, we can discuss them!
> 
> On a related note - I'm a bit confused about the ellipsis in the subject.
> Why "Change in ...qtgamepad[5.12.4]:" and not just "Change in
> qtgamepad[5.12.4]:"?

In the mail template there is a short project name.

$shortProjectName
The project name with the path abbreviated.

https://codereview.qt-project.org/Documentation/config-mail.html

Which replaces qt/ with ... as far as I can tell.
We could use the full project name instead, then you't get
Change in qt/qtgamepad[5.12.4]

I'm not sure which one I find better.

Cheers,
Frederik


> 
> Florian




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

Re: [Development] Gerrit is back / email template changed

[Frederik Gladhorn]

Quick update...

... after some contemplation and being made aware that the subject becomes 
rather long, we removed the [Gerrit] from the subject again. Filtering on the 
sender is easy enough.

If someone has other ideas, we can discuss them!

Cheers,
Frederik



On Tuesday, May 28, 2019 3:17:24 PM CEST Frederik Gladhorn wrote:
> Hi all,
> 
> We got the suggestion to change the email template, now the subject lines of
> 
 what Gerrit sends to your inbox will be a bit more helpful.
> 
> Old:
> Change in ...qtgamepad[5.12.4]: Add changes file for Qt 5.12.4
> 
> New:
> [Gerrit] Merged - ...qtgamepad[5.12.4]: Add changes file for Qt 5.12.4
> 
> So you get [Gerrit] as prefix and what happend after that.
> 
> Cheers,
> Frederik
> 
> 
> On mandag 20. mai 2019 15:00:57 CEST 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit is back / email template changed

[Frederik Gladhorn]

Hi all,

We got the suggestion to change the email template, now the subject lines of 
what Gerrit sends to your inbox will be a bit more helpful.

Old:
Change in ...qtgamepad[5.12.4]: Add changes file for Qt 5.12.4

New:
[Gerrit] Merged - ...qtgamepad[5.12.4]: Add changes file for Qt 5.12.4

So you get [Gerrit] as prefix and what happend after that.

Cheers,
Frederik


On mandag 20. mai 2019 15:00:57 CEST 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

Re: [Development] Gerrit is back

[Frederik Gladhorn]

On lørdag 25. mai 2019 18:11:59 CEST Richard Weickelt wrote:
> > There are more tweaks that would be nice to apply to the UI to make it
> > better. Does the new version make this any easier? What's your advice for
> > people who'd like to contribute UI tweaks? What's the best way to
> > proceed? (in the sense of empowering potential contributors instead of
> > asking you to do all the changes)
> 
> This is a very very positive way of saying that the new UI is:
> - less structured
> - less intuitive
> 
> The update contains indeed nice new features, but as an occasional
> contributor I feel less productive because I need to learn where to click
> every other day. The old gerrit was certainly ugly, but it felt much more
> tidy.
> 
> I would be very happy if someone with UI experience could clean up the
> stylesheet. :)

Please contribute upstream :) I'm sure they would also be happy about improved 
design.

We will simply follow upstream as much as possible, since lagging behind is 
not very sensible and forking doesn't help us either.

I was also a bit puzzled with the new UI at first, but after a few days I feel 
just as effective as in the old one. And the new UI works on mobile etc, which 
is also nice.

Cheers,
Frederik

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




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

Re: [Development] Qt 5.12.4 changes files

[Frederik Gladhorn]

On mandag 27. mai 2019 10:42:44 CEST Jani Heikkinen wrote:
> Hi,
> Initial ones here:
> https://codereview.qt-project.org/q/message:%2522Add+changes+file+for+Qt+5.
> 12.4%2522+status:open
> 
> Maintainers, please do needed modifications & make sure reviews are done
> during this week

Did the git log in the commit message get lost again?
I thought that was super helpful to confirm that there was no event (e.g. when 
the only commit was a version bump, I feel much better about approving the 
change stating that there was no change).

Cheers,
Frederik

> 
> br,
> Jani
> ___
> 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: Scheduled maintenance 20 May 2019

[Frederik Gladhorn]

Hi,

Staging for everything will now be disabled. Fingers crossed that tomorrow's 
Gerrit upgrade works nicely.

Greetings,
Frederik

From: Development  on behalf of Jukka 
Jokiniva 
Sent: Friday, May 17, 2019 9:34
To: development@qt-project.org
Subject: [Development] Gerrit: Scheduled maintenance 20 May 2019

Dear all,

Please read carefully, as this email contains important information.

We would like to remind you that codereview.qt-project.org will be unavailable 
due to scheduled maintenance. The aim is to upgrade our Gerrit Code Review to 
the latest version, 2.16. This upgrade includes a range of new features and a 
new web UI. Please refer to the public wiki for further information, 
https://wiki.qt.io/Gerrit_Upgrade_2019.

AFFECTED SYSTEMS
Gerrit Code Review (codereview.qt-project.org)
COIN (the continuous integration system)

DATE AND TIME
   Monday, 20 May 2019.
   Start: 06:00 EET (UTC + 2).
   Estimated end: 18:00 EET (UTC + 2).

During this time, codereview.qt-project.org will be unavailable.
Furthermore, staging rights will be temporarily removed for ALL USERS on SUNDAY 
19 MAY 1800 EET (CET + 2). Any on-going integrations in COIN will be canceled 
and both services will be shut down when the maintenance break starts.

We will send an alert before shutting down the system Monday morning. Upon 
successful completion, all access will be restored and we will notify the 
mailing lists accordingly.


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

Re: [Development] Requesting a module for Qt Quick Timeline Implementation

[Frederik Gladhorn]

Hi Thomas,

Since the module exists, it's a bit unclear to me what you request (creating 
the module would what I'd expect).
The next step would be to ask for inclusion in the releases and making a patch 
to qt/qt5 to enable us shipping the module by default.

Then there's the question which state the module would be in, I guess it's 
"addon" or so.

Cheers,
Frederik

On torsdag 9. mai 2019 10:21:55 CEST Thomas Hartmann wrote:
> Hi,
> 
> I would like to request for a new module:
> 
> Name of the repository: qt/qtquicktimeline.git
> Description: Module for keyframe-based timeline construction.
> Responsible person: Thomas Hartmann
> Gerrit user/email: thomas.hartm...@qt.io
> 
> The module is already on gerrit and is in a mature state by now.
> The timeline module is used by Qt Design Studio and Qt Quick Designer
> but there are use cases independent from tooling.
> 
> One use case is defining 'animations' not in time, but depending on an
> expression. This way it is very easy to create complex progress bars or
> gauges.
> 
> Best Regards,
> Thomas Hartmann




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

Re: [Development] Requesting a repository for UI analytics

[Frederik Gladhorn]

On fredag 10. mai 2019 13:09:37 CEST Minenko, Vladimir wrote:
> > Please consider the wider use-case too
> 
> 
> Ok, we will. So, is it a "go"?

OK, https://codereview.qt-project.org/#/admin/projects/qt/qtanalytics now 
exists.

Cheers,
Frederik

> 
> --
> Vladimir
> 
> On 10.05.19, 12:12, "Tor Arne Vestbø"  wrote:
> 
> 
> 
> 
> > On 10 May 2019, at 12:04, Kevin Funk  wrote:
> >
> >
> >
> > Kind of inconsistent with the naming of all other Qt module
> > repositories,
> > which all start with a "qt”.
> 
> 
> Right, that’s what I meant, sorry 
> 
> 
> 
> > On Friday, 10 May 2019 10:38:17 CEST Minenko, Vladimir wrote:
> > 
> >> Hi,
> >>
> >>
> >>
> >> the current implementation is focused on the use with Qt Quick. This
> >> is w/o
 saying that this topic does not have a future "below" the UI
> >> level. That makes sense, it is just not existent yet.
> 
> 
> 
> Please consider the wider use-case too 
> 
> Tor Arne
> 
> 
> 
> 
> 
> This e-mail and any attachment(s) are intended only for the recipient(s)
> named above and others who have been specifically authorized to receive
> them. They may contain confidential information. If you are not the
> intended recipient, please do not read this email or its attachment(s).
> Furthermore, you are hereby notified that any dissemination, distribution
> or copying of this e-mail and any attachment(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the
> sender by replying to this e-mail and then delete this e-mail and any
> attachment(s) or copies thereof from your system. Thank you.




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

Re: [Development] Requesting a repository for Alexa integration

[Frederik Gladhorn]

Now I'm looking forward to seeing what you've come up with :)

https://codereview.qt-project.org/#/admin/projects/qt/qtvoiceassistant

Cheers,
Frederik

On onsdag 8. mai 2019 16:47:24 CEST Minenko, Vladimir wrote:
> Thanks fort he feedback!
> 
> 
> > "qt/qtvoiceassistant"
> 
> 
> Sounds good! Thanks!
> 
> --
> Vladimir
> 
> On 08.05.19, 16:41, "Frederik Gladhorn"  wrote:
> 
> Hi Vladimir,
> 
> It's great to hear that you've been looking into integrating Alexa and
> other
 assistants as well, we have a few thoughts around this in The Qt
> Company and have been drawing how a rough abstraction for several
> assistants could look like. Sadly it's not easy to hook deeply into e.g.
> Alexa, but what you've done sounds very interesting. A later extension
> could also be to use QtMultiMedia with the Alexa SDK.
> 
> Moving/renaming repositories is generally a not very fun exercise, so
> we've
 been aiming to just use the final name, independent of the state.
> I'd suggest "qt/qtvoiceassistant", does that sound OK?
> 
> Cheers,
> Frederik
> 
> 
> On onsdag 10. april 2019 14:23:54 CEST Minenko, Vladimir wrote:
> 
> > Hi,
> >
> >
> >
> > I would like to request for a new repository:
> >
> >
> >
> > Name of the repository: qt-labs/qtalexa.git
> > Description: A environment enabling a use of Alexa an Qt based UI
> > systems.
> > Responsible person: Vladimir Minenko
> > Gerrit user/email: vladimir.mine...@pelagicore.com
> >
> >
> >
> > We developed an initial version of integration of Amazon Alexa in
> > Qt-based
> > UI. It can currently visualize selected cards (known as "Display
> > Cards") as
 well as use Custom Skills to post control command to a
> > system using Qt as UI framework.
> 
> 
> 
> > The current implementation is fully functional and was already used in
> > a
> > joint-development prototype with a customer. The mid- to long-term
> > intention is to create a new extension for Qt which would enable using
> > of a
 voice assistance in Qt based applications and systems. The code
> > will be licensed under (L)GLPv3 and commercial licenses.
> 
> 
> 
> > --
> > Vladimir Minenko – Qt Automotive Platform, Luxoft Automotive * Munich
> > *
> > Germany * +49 170 8583617 * https://www.qt.io/qt-automotive-suite/ *
> > https://doc.qt.io/QtAutomotiveSuite/
> 
> 
> 
> >
> >
> >
> > 
> >
> >
> >
> > This e-mail and any attachment(s) are intended only for the
> > recipient(s)
> > named above and others who have been specifically authorized to
> > receive
> > them. They may contain confidential information. If you are not the
> > intended recipient, please do not read this email or its
> > attachment(s).
> > Furthermore, you are hereby notified that any dissemination,
> > distribution
> > or copying of this e-mail and any attachment(s) is strictly
> > prohibited. If
> > you have received this e-mail in error, please immediately notify the
> > sender by replying to this e-mail and then delete this e-mail and any
> > attachment(s) or copies thereof from your system. Thank you.
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail and any attachment(s) are intended only for the recipient(s)
> named above and others who have been specifically authorized to receive
> them. They may contain confidential information. If you are not the
> intended recipient, please do not read this email or its attachment(s).
> Furthermore, you are hereby notified that any dissemination, distribution
> or copying of this e-mail and any attachment(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the
> sender by replying to this e-mail and then delete this e-mail and any
> attachment(s) or copies thereof from your system. Thank you.




___
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

[Frederik Gladhorn]

On onsdag 8. mai 2019 16:06:02 CEST Edward Welbourne wrote:
> On 8 May 2019, at 10:24, Liang Qi  mentioned:
> https://codereview.qt-project.org/260927
> 
> Shawn Rutledge (8 May 2019 15:43) replied
> 
> > I don’t understand why a change that is just sitting there on Gerrit
> > can affect the merge. Nobody ever staged that one onto the “wrong”
> > branch, right?
> 
> None the less, IIUC, apparently the automation involved did stage the
> 5.13.0 one when a merge to 5.13.0 (presumably the end of soft-branching)
> brought in the change from 5.13 with the same ID, that had been merged
> to 5.13 earlier.  Quite why that would happen is unclear, and may be
> considered a bug in whatever automation did it, but it seems this does
> happen.
> 
> > And then the bot detected the duplication and auto-abandoned it.
> 
> No, the whole point of Liang's message is that he had to abort the build
> (it wasn't auto-detected) and Frederik (an admin) had to manually
> abandon it so that he could get on with his merge.

Actually I don't understand why it had to be abandoned, but since it was 
clearly a duplicate, I didn't really care.

Cheers,
Frederik

> 
>   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] Requesting a repository for UI analytics

[Frederik Gladhorn]

Hello Vladimir,

On onsdag 10. april 2019 14:21:21 CEST Minenko, Vladimir wrote:
> Hi,
> 
> I would like to request for a new repository:
> 
> Name of the repository: qt-labs/qtuianalytics.git
> Description: An plugin for Qt Quick allowing collection of UI usage
> analytics.
 Responsible person: Vladimir Minenko
> Gerrit user/email: vladimir.mine...@pelagicore.com
> 
> We developed an initial version of a Qt Quick plug in allowing collection of
> UI usage analytics. It can be used in almost any QML item. It currently
> uses Matomo (former Piwik) as a web-based storage and visualization
> backend.
 
> The current implementation is fully functional and was already used in a
> joint-development prototype with a customer. The mid- to long-term
> intention is to create a new extension for Qt which would enable collection
> of UI usage data and a basic visualization with standard, mostly web-based
> analytics services, like Matomo. The code will be licensed under LGLPv3 and
> commercial licenses.

Is it always going to be UI? Maybe a more general name would make sense?

I struggle to come up with a great name though.

The Qt Company plans to gather some usage statistics from our products, e.g. 
Qt Creator, to learn better which platforms matter to our users. There is 
indeed some overlap, but in the meantime we have settled on using 
KUserFeedback, since Volker Krause has been really helpful and it provides 
what we need. It will be interesting to see how your implementation is 
different.

I'd vote for creating the repository, but assuming it aims to become part of 
Qt, with qt as namespace. "qt/qtuianalytics", unless someone comes up with a 
better name.

Cheers,
Frederik

 
> --
> Vladimir Minenko – Qt Automotive Platform, Luxoft Automotive * Munich *
> Germany * +49 170 8583617 * https://www.qt.io/qt-automotive-suite/ *
> https://doc.qt.io/QtAutomotiveSuite/
 
> 
> 
> 
> This e-mail and any attachment(s) are intended only for the recipient(s)
> named above and others who have been specifically authorized to receive
> them. They may contain confidential information. If you are not the
> intended recipient, please do not read this email or its attachment(s).
> Furthermore, you are hereby notified that any dissemination, distribution
> or copying of this e-mail and any attachment(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the
> sender by replying to this e-mail and then delete this e-mail and any
> attachment(s) or copies thereof from your system. Thank you.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

Re: [Development] Requesting a repository for Alexa integration

[Frederik Gladhorn]

Hi Vladimir,

It's great to hear that you've been looking into integrating Alexa and other 
assistants as well, we have a few thoughts around this in The Qt Company and 
have been drawing how a rough abstraction for several assistants could look 
like. Sadly it's not easy to hook deeply into e.g. Alexa, but what you've done 
sounds very interesting. A later extension could also be to use QtMultiMedia 
with the Alexa SDK.

Moving/renaming repositories is generally a not very fun exercise, so we've 
been aiming to just use the final name, independent of the state.
I'd suggest "qt/qtvoiceassistant", does that sound OK?

Cheers,
Frederik


On onsdag 10. april 2019 14:23:54 CEST Minenko, Vladimir wrote:
> Hi,
> 
> I would like to request for a new repository:
> 
> Name of the repository: qt-labs/qtalexa.git
> Description: A environment enabling a use of Alexa an Qt based UI systems.
> Responsible person: Vladimir Minenko
> Gerrit user/email: vladimir.mine...@pelagicore.com
> 
> We developed an initial version of integration of Amazon Alexa in Qt-based
> UI. It can currently visualize selected cards (known as "Display Cards") as
> well as use Custom Skills to post control command to a system using Qt as
> UI framework.
 
> The current implementation is fully functional and was already used in a
> joint-development prototype with a customer. The mid- to long-term
> intention is to create a new extension for Qt which would enable using of a
> voice assistance in Qt based applications and systems. The code will be
> licensed under (L)GLPv3 and commercial licenses.
 
> --
> Vladimir Minenko – Qt Automotive Platform, Luxoft Automotive * Munich *
> Germany * +49 170 8583617 * https://www.qt.io/qt-automotive-suite/ *
> https://doc.qt.io/QtAutomotiveSuite/
 
> 
> 
> 
> 
> This e-mail and any attachment(s) are intended only for the recipient(s)
> named above and others who have been specifically authorized to receive
> them. They may contain confidential information. If you are not the
> intended recipient, please do not read this email or its attachment(s).
> Furthermore, you are hereby notified that any dissemination, distribution
> or copying of this e-mail and any attachment(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the
> sender by replying to this e-mail and then delete this e-mail and any
> attachment(s) or copies thereof from your system. Thank you.
> ___
> 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] Gerrit Upgrade

[Frederik Gladhorn]

Hello,

We've been working on the Gerrit Upgrade for a while now and we are finally 
getting ready to deploy the new goodness.

We have all patches in our fork (yes, sadly we continue diverging a bit from 
mainstream, adding our own state handling for the CI).
The good news is that there are very few changes to Gerrit itself and most of 
the code is now in a self-contained plugin.

We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, that's 
a Monday, we assume Gerrit will be down for the full day that day).
The plan is to not actually take that long, but we want to make sure things 
actually work after the long wait and there are one or two things we cannot 
test very well without the right domain and everything in place.
Things look good though and I'm fairly confident that we'll manage the upgrade 
in May.

We will collect some documentation here, currently it's just a placeholder 
page, not yet worth visiting, unless you know the newer Gerrit and want to 
help out documenting what is new:
https://wiki.qt.io/Gerrit_Upgrade_2019

Cheers,
Frederik



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

Re: [Development] Gerrit Bot closing reopened Bugs?

[Frederik Gladhorn]

On fredag 15. mars 2019 14:05:39 CET Robert Loehning wrote:
> Hi *,
> 
> imagine the following situation:
> 1. Bug in 5.13 is reported
> 2. Patch with "Fixes: " is merged to 5.13 branch
> 3. Gerrit Bot closes the report with "Fix Version 5.13".
> 4. Reporter tests 5.13 branch, fix failed, reopens report
> 5. Patch is merged to dev branch
> 6. Gerrit Bot finds the patch in dev branch
> 
> What will the Gerrit do now? Will it close the reopened bug report 
> again? I'm asking because this seems to have happened in
> https://bugreports.qt.io/browse/QTCREATORBUG-21994
> (with Creator's branches 4.9 and master)
> 
> The Gerrit Bot should not close bug reports which were reopened unless 
> there is another patch. If this really happened as I suspect here, could 
> someone please fix it?

Indeed, I agree. This was something I didn't consider when writing the bot.

I want to fix this issue, but I'm not sure when I'll get around to fixing it. 
So far it was developed internally, but I just created a request on Gerrit to 
let you review the code:
https://codereview.qt-project.org/#/c/257050/

I think it should be very doable to extend the bot to check if the last 
transition was a re-open, in which case it could just drop a message and not 
close the bug again.

Cheers,
Frederik


> 
> Cheers,
> Robert
> 
> -- 
>Robert Löhning, Software Engineer - The Qt Company GmbH
>The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
>Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
>Sitz der Gesellschaft: Berlin,
>Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

Re: [Development] CMake branch

[Frederik Gladhorn]

Hello,

I really like the idea Mikhail proposed. I would even go as far as to add one 
platform where we start testing building Qt with CMake in the CI once we reach 
a level where we are comfortable with it.

I think it makes sense to get the CMake port more exposed and let people play 
with it in a convenient way. In the best case, we could switch build system 
even earlier than Qt 6. For many users it's an implementation detail how Qt is 
built. The plan is to still build qmake and generate the needed pri/pro files 
so that applications can use qmake as their build system.

For everyone that does build Qt themselves, moving to a more standard way of 
doing things (CMake rather than qmake) is an advantage, most people have to 
deal with cmake anyway.

Doing simple changes to the build system are trivial in cmake and qmake (e.g. 
adding/renaming files and so on). More complex changes should be reflected in 
both. For this port to succeed, an incremental port where we can expand to 
more platforms and more modules seems most promising to me.
I'd move over to cmake and ninja for my needs instantly if I could.

Cheers,
Frederik



On torsdag 21. mars 2019 13:00:55 CET Mikhail Svetkin wrote:
> Hi everyone!
> 
> 
> We’ve had an internal discussion about wip/cmake branch.
> 
> 
> We thought maybe it is a good idea to merge wip/cmake into dev branch.
> 
> 
> The advantages are:
> 
>  - It allows our contributors to play with CMake in dev branch
> 
>  - Speed-up the build of QtBase
> 
>  - Easy to find a lot of bugs in CMake port
> 
>  - CI could have a nightly build with CMake and generate a report
> 
>  - We can synchronize CMakeFiles and *.pro files
> 
> 
> The disadvantages are:
> 
>  - Any changes should be passed by CI
> 
> 
> Do you have any objections?
> 
> Best regards,
> Mikhail




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

Re: [Development] Qt QML Maintainer change

[Frederik Gladhorn]

This is great news, I'm happy to see Ulf taking over while Simon will be able 
to give advice.

+1 (in case that wasn't clear)

Cheers,
Frederik

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




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

Re: [Development] codereview, merge please

[Frederik Gladhorn]

On fredag 15. februar 2019 12:21:43 CET Martin Koller wrote:
> On Freitag, 15. Februar 2019 11:08:18 CET Andy Shaw wrote:
> > Since it has the +2 you can click on the "Merge patch 2 to staging" now,
> > is that button showing up for you?
> ah, great. Was not aware that I needed to trigger that.
> My fault. Was thinking the maintainer does that.

Thank you for contributing to Qt Martin!

This goes of course for all contributors, it's greatly appreciated that you 
make Qt better!

Sometimes Gerrit (especially the old version running on codereview.qt-
project.org) is not the most obvious to use.
For the people regularly using it, it tends to work nicely, but I can 
understand how it's just different enough from other Git workflows to be 
confusing.

Cheers,
Frederik


> Thanks!
> 
> > Andy
> > 
> > -Opprinnelig melding-
> > Fra: Development  på vegne av Martin
> > Koller  Dato: fredag 15. februar 2019 11:04
> > Til: "development@qt-project.org" 
> > Emne: [Development] codereview, merge please
> > 
> > Hi,
> > 
> > I made a patch here
> > https://codereview.qt-project.org/#/c/249171/
> > 
> > but it's still not merged.
> > Did I forget something ?




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

Re: [Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

Hi,

On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote:
> Summing up the discussion here. It looks like people overall agree that the
> pinned dependency approach (option 3) sounds better than what we currently
> have. The main concern was CI capacity, but Frederik believes that with
> enough storage capacity for build artefacts this will not be worse than
> what we have today with all the failed qt5.git integrations.
 
> The only other option that was seriously considered was a more monolithic
> repo (option 4). Disadvantages here are that it would require more work on
> the CI front to make testing times bearable, and it doesn’t give us a very
> flexible approach with regards to adding/removing modules. This is
> something that option 3 will nicely give us, as it treats all repositories
> the same way. Option 3 does btw not exclude that we later on merge some
> repositories if we feel that makes sense.
 
> So let’s go with option 3. Frederik will be leading the work to get this
> implemented. 
 
> As far as I can see, it requires some changes to CI so that we have the
> dependencies encoded in each repository, a bot to automatically push sha1’s
> of dependencies forward and some monitoring to alert us if modules get left
> behind.


I have indeed been playing with this, and I think I have an implementation
that works when it comes to resolving dependencies based on the idea.

After some pondering and starting with ini files, I settled on yaml, since we 
probably want to extend the data later on and I would like this to be easily 
human and machine read- and writable.

My current files look like this:
 dependencies:
 qt/qtbase:
 ref: 698078680fc5a6870177af285fa50c0d8a7c0bc3
 url: code.qt.io
 qt/qtsvg:
 ref: 2ae3c52fc061f574c9582bf58963fb3996724fbf
 url: code.qt.io


This is for qt/qtdeclarative, sha1's taken from qt5.git at some point.
Then there is the question of what the file name should be. Should it be at 
the top-level or in a coin subdirectory? dependencies.yaml?


I have not yet worked on the bot doing the module updates (which may turn out 
to be the harder part).
I don't think this can go live before we have that written as well.

Cheers,
Frederik

 
> Cheers,
> Lars
> 
> 
> > On 30 Jan 2019, at 11:11, Edward Welbourne 
> > wrote:
> > 
> > Robin Burchell (30 January 2019 10:13)
> > 
> >> I will admit that a monorepo has a _different_ set of problems
> >> (including but not limited to: longer build times, longer test times,
> >> flaky tests in unrelated areas blocking changes),
> > 
> > 
> > It also makes it easier to cope with API changes, which is great where
> > it's public APIs that haven't yet been shipped, but also makes it easier
> > to get away with using private APIs between components that really
> > shouldn't do that.  One of the classic reasons for modularisation at the
> > VC layer is that it makes this sort of thing harder, which means it
> > happens less, which is good.
> > 
> > There's also the problem of scope - which things go in the monorepo,
> > which should be outside.  We have that today, with qt5/, and we should
> > probably hoist some of its pieces outside, if only to force ourselves to
> > make it easy for a sizeable component to live happily outside; that
> > would enable folk in our ecosystem to live happily alongside, rather
> > than inside, Qt.  If we insist on solving that as part of a switch to a
> > monorepo, then we win (even if we could have done it without the
> > switch), if only because a major upheaval is an opportunity to make
> > other needed changes.  But if we move to a monorepo without solving that
> > problem, there's a significant risk we'll be making things harder for
> > those who work outside but close to Qt.
> > 
> > 
> >> but those problems are not complex, and can be fixed with some
> >> dedicated application of smarter scripting at build/test time
> > 
> > 
> > I remain to be convinced.
> > 
> > 
> >> (for instance: if change is doc only, don't run any test that _isn't_
> >> related to documentation, to cover one complaint from earlier in this
> >> thread).
> > 
> > 
> > This sort of thing [*] sounds terribly sensible and feasible, until you
> > start running into changes that the submitter and reviewers all *think*
> > should only have impact in a bounded area, but that turns out to break
> > stuff in surprising places outside those bounds.  That's probably rare
> > but when it happens it'll gum up the works - in a seemingly not very
> > related area that's been caught in the cross-fire.  In particular, this
> > sort of thing happens more readily when disparate things use each
> > others private APIs, as sketched above.
> > 
> > [*] The case of doc fixes is probably relatively safe, of course; but if
> > this is applied to other changes, we can't be assured of as much safety.
> > One of the scripts involved in my API change review generator knows to
> > ignore various changes that "make no 

Re: [Development] HDR Support in Qt and Angle

[Frederik Gladhorn]

Hi Dmitry,

Thanks for all the hard work :) It's not my area, so I won't be able to 
comment on the patches as such.

Please add reviewers to all patches, so they don't get forgotten. While that's 
quite some work, many people will only see email notifications from gerrit, or 
look at their dashboards, and it's easy to miss a dependency like that.

Cheers,
Frederik


On tirsdag 5. februar 2019 17:19:29 CET Dmitry Kazakov wrote:
> Hi, all!
> 
> I have finally published my HDR patchset in gerrit! It was the first time I
> pushed something into gerrit, so if I did something wrongly, please tell :)
> 
> https://codereview.qt-project.org/#/c/252187/
> 
> There are a few general questions I would like to ask your opinion about:
> 
> 1) Is it okay to list all the available colorspaces in
> QSurfaceFormat::ColorSpace? It leads to the fact that qsurfaceformat.h
> should be included in quite a lot of places. I wonder if you think it is
> okay.
> 2) Is API for color space support
> (QOpenGLContext::isSurfaceColorSpaceSupported()) actually needed for Qt?
> See patch [1]. I first implemented it, but then found that I will have to
> do "config probing" anyway. So, technically, this API is not needed for
> Krita and HDR implementation, but it might be used as a first-line check by
> someone...
> 3) Ideally, setTextureColorSpace() method should also be implemented for
> QOpenGLWindow. Right now it just defaults to DefaultColorSpace.
> 4) Should I add some tests to Qt? If yes, where?
> 
> To test HDR, you can use this simple app:
> https://github.com/dimula73/hdrtest
> 
> 
> [1] - https://codereview.qt-project.org/#/c/252185/1
> 
> On Mon, Nov 26, 2018 at 6:14 PM Boudewijn Rempt  wrote:
> > On maandag 26 november 2018 13:14:12 CET Allan Sandfeld Jensen wrote:
> > > It depends on what you want. Using Display P3 for instance is just
> > > wide-gamut not HDR. You can get that with just the new color-space
> > 
> > support
> > 
> > > and higher non-extended color precision. That is the primary motivation
> > 
> > for
> > 
> > > doing that first as wide-gamut monitors are already on the market and in
> > > the hands of many (high-) end-users. Where HDR is still mostly
> > > non-standardized on PC monitors.
> > 
> > We're specifically working on support for the VESA DisplayHDR standard:
> > https://displayhdr.org/ . I'm testing with a ASUS ROG Swift PG27UQ
> > monitor.
> > 
> > > The use of extended RGB, as scRGB is also known, is very useful behind
> > 
> > the
> > 
> > > scenes in any case, as using that you can map to and from any
> > > color-space
> > > without clamping, so we can keep something that is internally like sRGB,
> > > while still supporting wide-gamut by later taking the extended-sRGB and
> > > turning it back into a non-extended wide-gamut image. This makes it
> > > possibly to put the clamping and final color-space conversion in the
> > > QPA,
> > > while keeping the rest generic. So I would still support at least
> > > linear-scRGB (aka extended-linear- sRGB), even if only as an
> > > intermediate
> > > format.
> > > 
> > > It is arguably a strange non-sensical format with many impossible
> > > colors,
> > > but it is also very useful.
> > > 
> > > Also doesn't BT.2020 also require extended color-values above (1.0, 1,0,
> > > 1.0) in most encodings?
> > 
> > Well... We're not doing image manipulation using Qt classes. We simply
> > have a
> > buffer, handle that using opencolorio (which has suddenly seen a huge
> > amount
> > of development) to generate another buffer that gets stuffed into f16
> > textures
> > and displayed. The amazing thing is that we've actually massaged Angle and
> > Qt
> > into making that possible using QOpenGLWidget.
> > 
> > The result is a set of patches that we want to clean up and upstream :-)
> > 
> > --
> > https://www.krita.org___
> > Development mailing list
> > developm...@lists.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] gnuwin32 in qt5.git

[Frederik Gladhorn]

On fredag 18. januar 2019 14:26:50 CET Simon Hausmann wrote:
> I’m a fan of the idea that for Qt6 we remove all copies of third party
> libraries and provide convenient binaries of them in the qt installed (as
> separate package in there) as well as via vcpkg for those wanting to build
> from source.

I completely agree, for Qt 6 we should do this in a different way.
 
> Flex and bison are IMO exactly the same kind of third party software (except
> that gnuwin32 offers installer executables). Therefore I suggest to not
> have them in a repo but require the presence in the PATH and provide
> binaries in the installer.

I'd like to have a solution now that gets us there step by step. It sounds as 
if it's easy to add them to the installer, so we can for now just provide a 
zip file for now and provision that in the CI as interim solution.

Cheers,
Frederik


> Simon
> 
> 
> > On 18. Jan 2019, at 14:11, Frederik Gladhorn 
> > wrote:
 
> > Hi all,
> > 
> > I'd like to have some opinions about the gnuwin32 we currently have in 
> > qt5.git. This way we provide flex and bison for Windows.
> > I think it's a bit mis-placed, in my opinion the tools which are needed on
> > 
 Windows should be in their own sub-module.
> > 
> > I think we should continue to ship them as dependencies and have them 
> > available easily for developers. But placing them directly in the qt5 
> > repository makes little sense. In Coin we have weird work around and more
> > code 
 that should be needed to make sure they are always in the right
> > place. 
> > Assuming there are no better ideas, I'll request a new repository soon.
> > 
> > Cheers,
> > Frederik
> > 
> > 
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development




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

Re: [Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

On tirsdag 29. januar 2019 11:07:55 CET Alex Blasche wrote:
> >From: Development  on behalf of
> >Frederik Gladhorn 
> 2 Heads: use the latest revision of each branch (the system we used to have
> in the past)
> 
> >3 Modules containing pinned dependency sha1s
> >
> >Each module is completely self-contained, that means qt5 is not
> >
> >required as such (but may still exist as a collection of all modules, for
> >convenience and releases). In each module we have a list of dependencies
> >and their sha1.
> >
> >Updates for a release (and also otherwise) must happen regularly
> >(e.g.
> >
> >nightly), moving each module forward towards newer dependencies, this would
> >be implemented as bot which updates the above mentioned requirements file.
> I like this one. As you mentioned, we kind of had it already with
> sync.profiles.And really, if you implement this option you can almost
> implicitly run option 2 above too. In fact some modules might even want to
> do that if you permit SHA definition based on HEAD of some other
> repo/branch.
> 
>  There is one big question though. I vaguely recall one of the reasons for
> going to today's model was to limit the number of potential builds. This
> model could have 10 different modules/repos using different SHA's for all
> of its dependencies. Doesn't this increase the amount of different module
> builds which you have to store for later CI runs or build e.g. qtbase more
> often? Do we have the capacity/storage for it?

Yes, this is what we ended up with as well, module pinning seems like the way 
to go. It seems to solve a bunch of issues and we'd like to try implementing 
it (a few lines in how the CI resolves dependencies and writing the bot that 
bumps dependencies forward).

The capacity is something to look at, but considering how many failed qt5.git 
updates we have, I'm actually hoping that we get a better success rate with 
this model.

Other things to figure out are provisioning (how we prepare the VMs on which 
we build and test) and what the files specifying the dependencies should look 
like.

So option 3 is the favorite, but we need to clarify a few details.

Cheers,
Frederik


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




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

Re: [Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

On onsdag 30. januar 2019 09:17:11 CET Alex Blasche wrote:
> >From: Development  on behalf of Jedrzej
> >Nowacki >
>  >Personally, I also do like the idea of monolithic repo, while keeping
> >
> >modularization on the logical / build level. In our current state I see two
> >major problems:
> >- our build is quite monolithic in practice. For example qtbase always
> >needs to be build. CI currently caches builds on repository level (caches
> >results of make install) with monolithic repository the optimization would
> >need to be reconstructed on the build level. Conceptually it is good, but
> >someone would need to do the work.
> >- as a consequence of a partial build, the repository may be in a broken
> >state, for example not compiling. It can be solved by time based world
> >rebuilding and tagging known good revisions, but some policies would need
> >to be created.
> 
> I am clearly missing something here. Could you please outline why such a
> monolithic repo would be good? As you pointed out yourself, the conceptual
> problem that different libraries won't walk in lockstep remains and
> segmented builds continue to be desired. Sure, repo checkout is easier but
> as long as segmentation exists I fail to see the advantage.

A mono repo is good because it allows changing API across modules in on go.
There are a bunch of things speaking in favor of this, but the practicalities 
are quite hard - how would we do CI for this? How would we merge between the 
mono repo and the existing individual repos?

In the end we discarded the idea as impractical for the time being. It would 
be possible for someone to champion it by showing a lot of git magic and 
coming up with a good testing strategy where things work together nicely, but 
I fear that the complexity is quite high. With unlimited resources we could of 
course test everything in the repo for each change. Other options would be to 
try to figure out which tests are relevant for which change. Doing that cross-
platform in a sensible way seems quite non-trivial as well.

Cheers,
Frederik


> 
> --
> Alex
> ___
> 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

[Frederik Gladhorn]

On fredag 25. januar 2019 21:40:07 CET Thiago Macieira wrote:
> On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote:
> > I do quite like what Allan suggested: We could try the cherry-pick the
> > other way around. Volker, Lars, Thiago etc. surely remember the p4i
> > script we used to have when we were using Perforce. Imagine that with
> > more
> > automation.
> 
> I vaguely remember it. But your bringing it up is *not* an argument in
> favour of cherry-picking. Doing backporting properly in the Perforce days
> was a nightmare. We did not consistently backport fixes to earlier
> releases, even when we had a somewhat long stable series (4.3 went through
> 4.3.5).
> 
> Also, unlike Git, Perforce "merges" *were* a series of cherry-picks and it
> did know which commits had been cherry-picked and which ones hadn't. So if
> you told it to merge a range, it would tell you everything that was
> missing. More importantly, the range did not have to be contiguous, so you
> could cherry-pick only your own changes and let others deal with theirs. It
> also helped p4 had a pretty good automated conflict resolution in the
> command-line (today, I use kdiff3 for that, via git mergetool).

There is "git cherry" which tries to determine if something has been cherry-
picked between branches. But it's clearly not the most widely known, nor one 
of the best tools in the git offering. I have to look up up the order of 
source and destination arguments every time I run it... and then I still get 
it wrong. And indeed, the information that a cherry-pick happened is not 
properly recorded (which is why git cherry-pick -x is pretty much a must).

https://git-scm.com/docs/git-cherry

Cheers,
Frederik



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

Re: [Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

Here are the options we discussed internally. I'm happy to elaborate more in 
case something is unclear.


1 Do nothing / today / qt5.git

2 Heads: use the latest revision of each branch (the system we used to have in 
the past)

3 Modules containing pinned dependency sha1s
Each module is completely self-contained, that means qt5 is not 
required as such (but may still exist as a collection of all modules, for 
convenience and releases). In each module we have a list of dependencies and 
their sha1.
Updates for a release (and also otherwise) must happen regularly (e.g. 
nightly), moving each module forward towards newer dependencies, this would be 
implemented as bot which updates the above mentioned requirements file.

4 Monolithic repository for essentials
Merging at least qtbase and qtdeclarative and probably a whole lot 
more into one repository. Likely excluding webengine and webkit.

5 A way to stage breaking changes across modules (updating for example qtbase, 
qtdeclarative and qt5.git at the same time)
Presumably do some annotation of the commit message in Gerrit, or 
figure out how to connect changes in Gerrit in another way.



I made a small table on the wiki:
https://wiki.qt.io/Qt6_Enabling_API_Changes



Some notes:

1: is where we are today and in my opinion our processes get in our ways

2: we used to have this, it has the problem that some modules are always 
failing tests due to their dependencies changing. That's an unfortunate 
situation. We want to find out about breakages due to dependencies quickly but 
don't want to block development.

3: All modules get the same treatment and it makes things more consistent. At 
the same time we really need a bot then that moves modules forward with 
respect to their dependencies. We would also want to have a visualization that 
shows how much a module is behind e.g. qtbase (in days and number of commits).
We almost had this before in the form of sync.profile where pinning was an 
option.
This proposal does the pinning always and will result in a lot of commits that 
simply say: bump dependency versions.

4: Requires finding out how to run the CI on this. It's in many ways 
attractive, but we would always struggle with defining what's in and what not. 
I see Qt also as ecosystem where modules join and sometimes get left behind. 
We want to enable that more, so the mono repo approach seems tricky in that 
respect. That doesn't prevent deciding on some repos being merged. Merging 
between Qt 5 and 6 will then be harder though.

5: This is more of a cludge and could allow staging changes in qtbase and 
qtdeclarative at the same time while also trying to update qt5.git. It's a bit 
complex and needs people to be very aware of it and will block other changes 
from being processed at the same time.



Cheers,
Frederik



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

[Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

Hi all,

I'd like to start another discussion around our development workflow.
We arrived at our current model of Qt modules (in the git repository sense) 
and using qt5.git as a container for all of them through a series of steps and 
changes. Mix in the evolution of the testing environment over time and we have 
something that has grown in interesting ways.

I will try to describe the problem in this mail. I also have discussed with a 
bunch of people (inside The Qt Company) about potential solutions. After 
brainstorming and some back and forth, we had five suggestions on a whiteboard 
and picked our favorite. In a separate mail I'll try to describe these and 
what we concluded with as our favorite. All of this is up for discussion, so 
I'm hoping for someone to come up with even better ideas.


The problem:

qt5.git serves several purposes today, for example:
- it contains a few binaries needed for Windows development
- it gives a definition of which modules make up a Qt release
- it collects sets of revisions which work together (because they were tested 
with each other)
- it has a bit of build system infrastructure to build all of this

In my opinion there are a few issues with what we have:
- updating qt5.git (and thus making releases) is cumbersome
- it's unclear for many people what a module is tested against in the CI
  (its dependencies are checked out at the revisions specified in qt5.git, not 
the latest revisions of the corresponding branch)
- we have more products, such as Qt for Automotive, Automation, Device 
Creation, should those have qt5-special-purpose repositories?
- modules outside of qt5.git get different treatment, making it hard to 
include new modules

In the light of Qt 6, there is also the question of how we can allow making 
source incompatible changes in an easy fashion.
Why is it hard to do source incompatible changes? Let's say we want to rename 
a function in qtbase. qtdeclarative is the only user of that function in our 
code-base. Today we can do that in five easy steps:

1) add function with new name in qtbase, do not remove the old one yet
2) update qt5.git
3+4) move qtdeclarative to the new function name; remove the old function from 
qtbase
5) after 3 and 4 are in, update qt5.git

Five commits, two of which are qt5.git updates, is a lot to ask for. And this 
is assuming that the contributor knows of this work-flow and does everything 
by the unwritten book. In the unhappy case, we do an attempt of changing 
qtbase directly, then we notice qt5.git doesn't update and we need to bring 
back the old function name first. Another aspect is that even after 5, if this 
happened to be a branch other than dev, we might face all of these problems 
while doing merges to the next branch again (been there, done that, and so has 
Liang).

This has led to a mess in how we create releases and how we test things. It 
creates a very hard and artificial line of what's part of the core product and 
what is outside and testing in the CI is also majorly influenced by this.
Modules are not self-contained (since the fine-grained dependencies are 
specified in qt5.git). We don't know how to cleanly handle dependencies for 
modules outside. We have trouble getting some of the releases out, since Qt 
for Device Creation follows slightly different routines than Qt for 
Application Development

On a semi-related note, running git-bisect on anything but qtbase is a 
science, hard enough to at least put me off.

Cheers,
Frederik



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

Re: [Development] Stepping down as the Qt Quick Controls 2 maintainer

[Frederik Gladhorn]

Hi,

It's been a while, so I'd like to congratulate Mitch on becoming maintainer 
for Controls 2 :)

I'll update the wiki.

Cheers,
Frederik


On mandag 26. november 2018 19:39:03 CET J-P Nurmi wrote:
> Hi all,
> 
> As you may have noticed, I haven't been actively working on Qt Quick
> Controls 2 since last summer. I haven't had time to contribute, nor
> fulfill my maintainer duties. I would therefore like to step down, and
> propose Mitch Curtis as the new maintainer of the Qt Quick Controls 2
> module. Mitch participated in QQC2 development early on, and is a
> natural choice as the new QQC2 maintainer.
> 
> --
> J-P Nurmi
> ___
> Development mailing list
> developm...@lists.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] Issues with 'Fixes' keyword

[Frederik Gladhorn]

On torsdag 27. desember 2018 11:05:28 CET Christian Ehrlicher wrote:
> Am 27.12.2018 um 10:52 schrieb Allan Sandfeld Jensen:
> > It has been for me. I always put bugs I have a patch in review for "in
> > progress", and they have been consistently closed, except one time I found
> > a bug in the script that was then closed. You have probably run into
> > another bug. What else was special in this case?
> 
> I did not saw an obvious difference. Looks like there are others which
> are not closed in reporting state:
> https://bugreports.qt.io/browse/QTBUG-48505
> Maybe they're all in dev? At least my last ones for 5.12 were closed
> automatically.

I've been side-tracked, so I simply didn't get around to investigating this. 
Since having only me maintain this is not  a good idea, I'd like to make the 
sources to the fixes bot available. It's not much code. I'd have done that 
already, but then I was pondering which repository it should live in. 
Currently I have the bot in a Qt Company internal repository. It's about 150 
commits, a few Python files and tests.

Should this be a new repository on its own? Or would one of the existing repos 
be sensible?

Cheers,
Frederik

> 
> 
> Christian
> ___
> 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] gnuwin32 in qt5.git

[Frederik Gladhorn]

Hi all,

I'd like to have some opinions about the gnuwin32 we currently have in 
qt5.git. This way we provide flex and bison for Windows.
I think it's a bit mis-placed, in my opinion the tools which are needed on 
Windows should be in their own sub-module.

I think we should continue to ship them as dependencies and have them 
available easily for developers. But placing them directly in the qt5 
repository makes little sense. In Coin we have weird work around and more code 
that should be needed to make sure they are always in the right place.

Assuming there are no better ideas, I'll request a new repository soon.

Cheers,
Frederik



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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

Hi Uwe,

On torsdag 10. januar 2019 10:24:22 CET Uwe Rathmann wrote:
> On Thu, 10 Jan 2019 07:24:01 +0000, Frederik Gladhorn wrote:
> >> Ours is LGPLv2+ as usual, FWIW.
> > 
> > Which sadly makes it unsuitable for inclusion in Qt.
> 
> I'm maintainer of the Qwt library ( https://qwt.sourceforge.io/ ), that
> exists since Qt 1.1 - but there are also other popular Qt plotting
> libraries available. For some reason "Qt" decided to come up with the Qt/
> Charts module many years later - AFAIK without even trying to contact any
> existing project.
> 
> As being author of a competing package I never checked the code of the Qt/
> Chart module and can't ( and don't want to ) judge if it is good or bad.
> But my impression is, that it started with a limited set of features and
> immediately changed into maintenance mode without seeing much active
> development since then.
> 
> Don't you agree that supporting an existing project instead would have
> lead to a better overall situation for everyone ?

Absolutely, but The Qt Company is a company. It provides many services to the 
community, but it also needs to function as business. That is why we have the 
CLA for the Qt project, being able to monetize on the product makes it 
possible to invest into the development of the same.

> 
> Considering that you hardly get the existing modules maintained - why
> don't you start with thinking in a more community oriented way ?

I'd like to see more community focus from TQtC as well. At the same time, we 
are considering the community pretty much always. Sometimes we make 
unfortunate decisions (it's a company, neither good or bad, nobody's perfect).

I do not see how we could have avoided this in this instance - the module was 
internally written for a customer and we want to make it available for others 
to use. I was not aware that there is a KDE framework that does serve a 
similar purpose. Let's get the code out, then implementations can be compared 
by those interested. I agree that duplicating effort is a bad idea, sometimes 
is sadly hard to avoid.

Cheers,
Frederik


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




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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

On onsdag 9. januar 2019 17:26:06 CET Thiago Macieira wrote:
> On Wednesday, 9 January 2019 06:23:02 PST Tuukka Turunen wrote:
> > Description: Lottie-Qt, a renderer for Bodymovin animations
> 
> What's "Lottie" ? Is that an acronym? Or is it a trademark of something? If
> it's the latter, please find another name.

At least the page by airbnb doesn't claim any trademark.
https://airbnb.design/lottie/
They also provide libraries for Android, iOS and react-native as far as I can 
see licensed with Apache 2.0.

From what I can tell, we would follow their spirit and add another 
implementation of their image/animation file format, I don't see lottie 
mentioned as trademarked anywhere on their pages.

I'd propose we create the repo.

Side note:
We had a discussion internally yesterday among the gerrit administrators (yes, 
we are four people now that actively handle your requests).
We'll try to move this kind of request to JIRA, so that we can track it, since 
email tends to break down. That doesn't mean things should not be announced 
here (quite the opposite), but creating a task in QTQAINFRA with Gerrit as 
component will probably be the way to get any repository created/changed in 
the future.
To test that I created https://bugreports.qt.io/browse/QTQAINFRA-2536

Cheers,
Frederik



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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

Hi,

Thanks for pointing out that this alternative implementation exists.

On onsdag 9. januar 2019 17:18:50 CET Eike Hein wrote:
> Hi,
> 
> we've written one of those at KDE recently:
> 
> https://github.com/kbroulik/lottie-qml
> 
> We also submitted some patches to both Qt and Lottie to make it work
> better.
> 
> Ours is LGPLv2+ as usual, FWIW.

Which sadly makes it unsuitable for inclusion in Qt.

Our code is already written as well, so I guess we should publish it asap to 
avoid further duplication, maybe Kai wants to contribute some of his work that 
applies. I haven't seen the code that The Qt Company wrote and didn't know Kai 
did something similar.

Considering KDE also is interested in this kind of component, I'm for creating 
the repository now, so that we can compare implementations.

Now we should just clarify if the name lottie can be used, as Thiago pointed 
out.

Cheers,
Frederik


> 
> 
> 
> Cheers,
> Eike
> 
> On 1/9/19 11:23 PM, Tuukka Turunen wrote:
> >  
> > 
> > Hi,
> > 
> >  
> > 
> > I would like to request for a new repository:
> > 
> >  
> > 
> > Name of the repository: qt/qtlottie.git
> > 
> > Description: Lottie-Qt, a renderer for Bodymovin animations
> > 
> > Responsible person: Eirik Aavitsland
> > 
> > Gerrit user/email: eirik.aavitsl...@qt.io 
> > 
> >  
> > 
> > Lottie is a family of player software for a certain json-based  file
> > format for describing 2d vector graphics animations. These files are
> > created/exported directly from After Effects by a plugin called Bodymovin.
> > 
> >  
> > 
> > About Lottie: https://airbnb.design/lottie/
> > 
> >  
> > 
> > Intention is to create a Qt based player for these animations and
> > license it under GLPv3 and commercial licenses.
> > 
> >  
> > 
> > Yours,
> > 
> >  
> > 
> > Tuukka
> > 
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

Re: [Development] Nominating Paul Wicking for Approvership

[Frederik Gladhorn]

+1 from me as well.

Paul is interested in many areas and taking responsibility. He also started 
helping out maintaining our Gerrit instance.

Cheers,
Frederik

On onsdag 12. desember 2018 11:58:47 CET Simon Hausmann wrote:
> Hi,
> 
> 
> I would like to nominate Paul for approvership. He started beginning of 2018
> making changes to docs and reviewing doc changes. Whenever I made changes
> to docs, he has spotted many of my mistakes, so I've had a very good
> experience working with him ;-). I trust him to approve changes he's
> comfortable with.
> 
> 
> If you're curious, here's a list of his changes:
> 
> 
> https://codereview.qt-project.org/#/q/owner:%22Paul+Wicking%22,n,z
> 
> 
> and a list of changes he's on as a reviewer:
> 
> 
> https://codereview.qt-project.org/#/q/reviewer:%22Paul+Wicking%22,n,z
> 
> 
> 
> 
> Simon




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

Re: [Development] Nominating Christian Ehrlicher for Approver

[Frederik Gladhorn]

+1 from me as well :)

Cheers,
Frederik

On tirsdag 20. november 2018 09:38:00 CET Richard Gustavsen wrote:
> Hi,
> 
> I'd like to nominate Christian Ehrlicher for approver rights.
> 
> He has done a lot of work in Qt, especially Widgets and Item Views, with
> more than 150 patches being merged during the last year.
> 
> He has also been equally active in Jira, verifying bug reports, identifying
> duplicates, etc.
> 
> His work:
>  n,z>https://codereview.qt-project.org/#/q/owner:%22Christian+Ehrlicher%22,n,
> z
> 
> His reviews:
>  22,n,z>https://codereview.qt-project.org/#/q/reviewer:%22Christian+Ehrlicher
> %22,n,z
> 
> Br,
> Richard Moe Gustavsen




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

[Development] Bug in fixes bot

[Frederik Gladhorn]

Hi all,


I had a bug in the bot closing issues. It may have accidentally assigned fix 
version 5.12.0 beta 4 instead of 5.12.1 when changes went into 5.12 after the 
5.12.0 branching.

That's fixed now and the bot is running again after taking a break this 
afternoon.


Cheers,

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

Re: [Development] QUIP 12: Code of Conduct

[Frederik Gladhorn]

Hi all,

I would like to thank the people who have started this discussion. For me this 
is a very positive thing and a step forward for the Qt community.
I really enjoy being part of the community. I want it to continue to be the 
great group of people that it is today. And hopefully bigger, more diverse and 
inclusive going forward.
I am very sure that a big silent majority does support this initiative. Again, 
thank you!

Reading through the mails (an impressive amount), I feel there is consensus 
towards the KDE CoC. I also appreciate the positive wording.

Maybe we don't need many more mails in this thread, I have the feeling we will 
not discover a whole lot of new information at this point. I'd like us to move 
on to the next constructive phase of this process. Let's adopt the more 
positively phrased CoC from KDE. It is under a license that allows us to use 
it and is clearly meant to be picked up by others.

I am happy that so many people have strong opinions on our culture and value 
it. For me this is about culture, how we treat each other. That is what being 
a community is all about. We have a common goal - making Qt the best it can 
be, and nobody is able to do that alone. We will always have some style of 
communication in the project. I am happy when I see positive reviews. In my 
opinion that can be a -1 with good comments which problems to address. Let's 
set ourselves a high standard, on the communication side as well as on the 
technical one.
I hope we use this as an opportunity to remind ourselves that in reviews we 
should give ideas what to improve (and how). Reviews are important to share 
knowledge, which is important to us as community. In emails we should be 
respectful, on the forums sensible and so on. I think we mostly succeed 
nowadays.

Moving on... we should find out how to deal with the occasional problems that 
might arise. I do think that we want to establish some form of enforcement. I 
firmly believe that the first means of action in all cases will be an email or 
two, just to clarify the situation. Maybe a phone call. Often enough conflicts 
turn out to be small misunderstandings and we want a reasonable small group of 
people that keeps things confidential and just nudges people to talk to each 
other and move on.

Only when everything goes wrong should stronger measures ever be considered. 
Thus we want a group we can trust with making sensible decisions in how to 
uphold the CoC. I would want them to have some diplomatic skills, respect 
privacy and be sensitive to different cultures - good communicators.

Cheers,
Frederik



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

Re: [Development] wip/cmake status information

[Frederik Gladhorn]

I just changed it into a review request, so everyone can have a look in 
gerrit:
https://codereview.qt-project.org/#/c/244005/

Cheers,
Frederik



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

Re: [Development] wip/cmake status information

[Frederik Gladhorn]

I just changed it into a review request, so everyone can have a look in 
gerrit:
https://codereview.qt-project.org/#/c/244005/

Cheers,
Frederik



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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

Hello again,

After another round of fixing (such as allowing to close issues that are 'In 
Progress', because they have a different name for the transition), adding the 
setting of the commit sha1 and no longer setting too many versions, we should 
be live with a working bot.

I'm interested in issues that you encounter. I just let the bot run through 
all historical commits to fix them up and add for example the missing sha1s.

The rules are basically:
- if there is a lower patch level already in the fix versions, nothing is 
added
5.12.1 is there: do not add 5.12.2 or 5.12.3

- if there is a .0 release that is earlier than the current release, nothing 
is added
5.12.0 is there: do not add 5.13.0

Cheers,
Frederik



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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> One thing that would still be great to have is the jira links working so
> that the changes show up in JIRA like they do for Task-number, I'm looking
> into this and thought the config was fixed, but so far that doesn't seem to
> do the trick...

Looks like I nudged it in the right way nwo (writing the config slightly 
differently, why one version works and the other doesn't is beyond me).
You should now get jira to show gerrit links when using Fixes.

Cheers,
Frederik



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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

Quick update:
Sanity bot and commit template (in 5.11, soon other places) are now updated 
and the bot is running.

I'd appreciate if people tried using the Fixes: footer and let me know if the 
issue is closed with the right version (or even better, if the fix version is 
not set or incorrectly set).

Note that for some products in JIRA the versions are not in any way logical, 
so the bot will not set a fix version (QTQAINFRA and the 3d studio stuff for 
example).

One thing that would still be great to have is the jira links working so that 
the changes show up in JIRA like they do for Task-number, I'm looking into 
this and thought the config was fixed, but so far that doesn't seem to do the 
trick...

Happy bug fixing!

Cheers,
Frederik


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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On onsdag 29. august 2018 20.17.52 CEST Robert Löhning wrote:
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
> > Quick status update from my side:
> > I have the script running against a test installation of JIRA. It seems to
> > work, there are some small issues to be worked out still.
> > 
> > - Qt Creator version numbers are verbose, so I need to be more generous in
> > matching strings, right now I don't detect the version number correctly
> > there. This one I will fix, it's just going to take a few minutes.
> > 
> > - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA
> > versions are 2.x, I consider this a won't fix.
> > 
> > I'd love if people started using "Fixes:", it will work retro-actively.
> > And if you manually close a task in the meantime, no harm is done.
> 
> Looks like somebody should tell the sanity bot:
> https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG

Seems like nobody volunteered (surprise :P).

Sanity bot:
https://codereview.qt-project.org/#/c/238437/1

Commit template:
https://codereview.qt-project.org/#/c/238435/

I now consider the code done, no idea if/where it should live in the future, 
currently it's some internal repo inside TQtC. It's running in a VM and just 
needs the integration to be enabled in the real JIRA instance, so hopefully it 
goes live in the next few days :)

Cheers,
Frederik


> 
> Cheers,
> Robert
> 
> > Multiple fix versions:
> > There were some doubts about which fix versions would be set, for example
> > during the down-merge. This actually turns out to work quite nicely:
> > If a change ends up in dev, the script will detect that it will end up in
> > 5.13.0 right now and sets that as fix version. If the downmerge happens,
> > the script will see the change again in 5.12.0 and add that fix version.
> > In my opinion there is no major harm.
> > If the change is then cherry-picked to 5.9.7, it will also add that fix
> > version.
> > 
> > This also means that changes going into 5.11.4 will be marked as fixed in
> > 5.12.1 or whatever is applicable branch/version wise. So we will actually
> > set fix versions nicely.
> > 
> > There are some fixes in JIRA that would be easy to make, assuming there is
> > agreement. Since I have to use some heuristics, I decided to only ever
> > look at full version numbers, including patch level releases.
> > Currently we have version numbers in JIRA which do not make much sense to
> > me, since they will never be released, such as 6.0, 5.12 and a few more.
> > I would propose we always use the full version, so 6.0.0 and 5.12.0.
> > If the script finds 5.13 but not 5.13.0 it will not set any fix version.
> > 
> > I'm unsure where the whole thing should live, currently it's internal to
> > The Qt Company, I'd love to publish it somewhere (it's a bunch of python
> > files).
> > 
> > Cheers,
> > 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




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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

Quick status update from my side:
I have the script running against a test installation of JIRA. It seems to 
work, there are some small issues to be worked out still.

- Qt Creator version numbers are verbose, so I need to be more generous in 
matching strings, right now I don't detect the version number correctly there. 
This one I will fix, it's just going to take a few minutes.

- Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA versions 
are 2.x, I consider this a won't fix.

I'd love if people started using "Fixes:", it will work retro-actively. And if 
you manually close a task in the meantime, no harm is done.

Multiple fix versions:
There were some doubts about which fix versions would be set, for example 
during the down-merge. This actually turns out to work quite nicely:
If a change ends up in dev, the script will detect that it will end up in 
5.13.0 right now and sets that as fix version. If the downmerge happens, the 
script will see the change again in 5.12.0 and add that fix version. In my 
opinion there is no major harm.
If the change is then cherry-picked to 5.9.7, it will also add that fix 
version.

This also means that changes going into 5.11.4 will be marked as fixed in 
5.12.1 or whatever is applicable branch/version wise. So we will actually set 
fix versions nicely.

There are some fixes in JIRA that would be easy to make, assuming there is 
agreement. Since I have to use some heuristics, I decided to only ever look at 
full version numbers, including patch level releases.
Currently we have version numbers in JIRA which do not make much sense to me, 
since they will never be released, such as 6.0, 5.12 and a few more. I would 
propose we always use the full version, so 6.0.0 and 5.12.0.
If the script finds 5.13 but not 5.13.0 it will not set any fix version.

I'm unsure where the whole thing should live, currently it's internal to The 
Qt Company, I'd love to publish it somewhere (it's a bunch of python files).

Cheers,
Frederik



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

Re: [Development] New Qml Tableview

[Frederik Gladhorn]

Hi James,

On torsdag 9. august 2018 10.24.26 CEST James Maxwell wrote:
> I read that you target a new QML TableView for Qt5.12. In one of my
> projects I will need to do a lot with TreeViews. Will the new TableView
> also serve as a TreeView (This would be helpful information so I can decide
> whether I wait for the new TreeView)?

We want to get the table view right and it will do exactly that, display 
tables.
For tree views, either use the one from Controls 1 or roll your own. Of course 
it's possible to help us make progress towards a tree view in Qt Quick, but 
we'll first evaluate what we learned from the table view and then eventually 
move towards a good implementation of the tree. Some future version is the 
current estimate.

Cheers,
Frederik



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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote:
> Hi Frederik,
> 
> one more question: does the script also sets the final Git-SHA1 in the
> Jira "commits" field?
> 
> If yes, that would really be a *big* improvement.

Yes, that's the plan.

Frederik


> 
>  > Everything else (wip/foobar, other branch names) will be ignored,
>  > unless someone explains what to do with them otherwise.
> 
> I think that's acceptable.
> 
> André
> 
> Am 08.08.2018 um 11:58 schrieb Frederik Gladhorn:
> > On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> >>> -Original Message-
> >>> From: Development  >>> project.org> On Behalf Of Jani Heikkinen
> >>> 
> >>>> The plan is to update the fix versions and close the task as done when
> >>>> a line in the commit message starts with "Fixes:".
> >>>> If the issue is already closed (e.g. cherry-pick) it can add an
> >>>> additional fix version (e.g. 5.9.7).
> >> 
> >> The devil is in the detail. We don't want FixVersion to be set to 5.11
> >> but
> >> set to 5.11.x.  When you look at a bug 6 month down the road you don't
> >> want
> >> to know that it was fixed in 5.11 but you want to know the exact patch
> >> level release. Especially the LTS releases tend to have many patch lvl
> >> number.
> >> 
> >> This implies that the script needs to know when 5.11.x was branched off
> >> and
> >> that every following commit to 5.11 branch will imply 5.11.x+1. Whether
> >> x+1
> >> may never be released is irrelevant though as that's a simple bulk change
> >> when the decision to not have x+1 comes through. Is this what you intend
> >> to
> >> do?
> > 
> > Indeed, I have to make some assumptions.
> > Right now I have the simple case done: branch == x.y.z -> set fix version
> > to x.y.z.
> > 
> > Then there are two cases that I will handle:
> > branch is 'dev' or 'master' -> find the next minor version
> > branch is x.y -> find the next valid patch version
> > 
> > Everything else (wip/foobar, other branch names) will be ignored, unless
> > someone explains what to do with them otherwise.
> > 
> >>> I see at least one problem there: If bug is affecting to several
> >>> branches
> >>> it will be closed when fix for first branch is done even in that case it
> >>> shouldn't be closed until every branch has a fix...
> >> 
> >> That's the developer's decision as much as it is today already. If you
> >> know
> >> that the fix should go to multiple branches you should probably not use
> >> the
> >> "Fixes" keyword for the first commit but the existing "Task-number"
> >> keyword.
> > 
> > My plan was to let the bot add additional fix versions as changes move
> > through branches.
> > So if a Fixes: QTBUG- goes into 5.12.1, the bug gets closed and fix
> > version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot
> > will see the change again and will add a fix version 5.9.8.
> > 
> >>> Another concern or question is that in which phase we should close the
> >>> bug; is it done immediately when fix is in or should it be done when fix
> >>> is in the packages and someone can verify that fix is there and really
> >>> fixes the problem...
> >> 
> >> It can only ever be when it is in the code line. That's correct for 90%
> >> of
> >> all cases. We cannot optimize for the case when releasing becomes
> >> creative
> >> and starts shifting around SHA's or decides to create the package. I am
> >> sure releasing does not want to be responsible for setting the fix
> >> version
> >> across all tasks. It does not scale. In other words the status quo
> >> applies.
> > 
> > Agreed. There is no magic solution and we need to close bugs, even when
> > the
> > fix is not released yet, otherwise JIRA becomes useless.
> > Everyone will understand that if something is closed for 5.12.0 today, it
> > will not be in their copy of Qt 5.11.0.
> > Right now we often don't set the fix version at all, which is even more
> > harmful in my opinion.
> > 
> > Frederik
> > 
> >> --
> >> 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] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -Original Message-
> > From: Development  > project.org> On Behalf Of Jani Heikkinen
> > 
> > >The plan is to update the fix versions and close the task as done when
> > >a line in the commit message starts with "Fixes:".
> > >If the issue is already closed (e.g. cherry-pick) it can add an
> > >additional fix version (e.g. 5.9.7).
> 
> The devil is in the detail. We don't want FixVersion to be set to 5.11 but
> set to 5.11.x.  When you look at a bug 6 month down the road you don't want
> to know that it was fixed in 5.11 but you want to know the exact patch
> level release. Especially the LTS releases tend to have many patch lvl
> number.
> 
> This implies that the script needs to know when 5.11.x was branched off and
> that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1
> may never be released is irrelevant though as that's a simple bulk change
> when the decision to not have x+1 comes through. Is this what you intend to
> do?

Indeed, I have to make some assumptions.
Right now I have the simple case done: branch == x.y.z -> set fix version to 
x.y.z.

Then there are two cases that I will handle:
branch is 'dev' or 'master' -> find the next minor version
branch is x.y -> find the next valid patch version

Everything else (wip/foobar, other branch names) will be ignored, unless 
someone explains what to do with them otherwise.

> > I see at least one problem there: If bug is affecting to several branches
> > it will be closed when fix for first branch is done even in that case it
> > shouldn't be closed until every branch has a fix...
> 
> That's the developer's decision as much as it is today already. If you know
> that the fix should go to multiple branches you should probably not use the
> "Fixes" keyword for the first commit but the existing "Task-number"
> keyword.

My plan was to let the bot add additional fix versions as changes move through 
branches.
So if a Fixes: QTBUG- goes into 5.12.1, the bug gets closed and fix 
version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot will 
see the change again and will add a fix version 5.9.8.

> > Another concern or question is that in which phase we should close the
> > bug; is it done immediately when fix is in or should it be done when fix
> > is in the packages and someone can verify that fix is there and really
> > fixes the problem...
> It can only ever be when it is in the code line. That's correct for 90% of
> all cases. We cannot optimize for the case when releasing becomes creative
> and starts shifting around SHA's or decides to create the package. I am
> sure releasing does not want to be responsible for setting the fix version
> across all tasks. It does not scale. In other words the status quo applies.

Agreed. There is no magic solution and we need to close bugs, even when the 
fix is not released yet, otherwise JIRA becomes useless.
Everyone will understand that if something is closed for 5.12.0 today, it will 
not be in their copy of Qt 5.11.0.
Right now we often don't set the fix version at all, which is even more 
harmful in my opinion.

Frederik

> 
> --
> Alex




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

Re: [Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
> 
> so why exactly are you doing this after i implied in
> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
> look at
> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> did your investigation reveal that it's unsalvagably bad?

I guess it could work, it can close issues, but it doesn't have any idea about 
versions. I just looked at the code now.

> 
> after the elusive gerrit upgrade (hey, we finally have someone assigned
> to that now (!)), either script based solution will be obsoleted by
> deploying
> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
> anyway.

I was not aware of/forgot that comment. I am also unsure if I want to wait for 
that gerrit update to manifest.
I'd really like to get the fix version set, so that we can generate change 
logs more easily when it comes to fixed issues for each release.

Cheers,
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] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 15.23.52 CEST Robert Löhning wrote:
> Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
> > Hi all,
> > 
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
> > Basically it should be able to set the fixed version and close tasks
> > automatically.
> > 
> > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the
> > keyword to trigger this.
> > 
> > The plan is to update the fix versions and close the task as done when a
> > line in the commit message starts with "Fixes:".
> > If the issue is already closed (e.g. cherry-pick) it can add an additional
> > fix version (e.g. 5.9.7).
> > 
> > Note: Task-number will be used as before as "this is related to the issue
> > in some way".
> > 
> > Cheers,
> > Frederik
> 
> Hi,
> 
> would that work for all project in JIRA immediately or only in QTBUG?

It should work for all.

Frederik

> 
> Cheers,
> Robert
> ___
> 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] Closing issues automatically with new keyword

[Frederik Gladhorn]

Hi all,

I've spend a bit of time writing a script that monitors gerrit and the git 
repositories to update JIRA statuses. It's not quite done yet, but getting 
there.
Basically it should be able to set the fixed version and close tasks 
automatically.

Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword 
to trigger this.

The plan is to update the fix versions and close the task as done when a line 
in the commit message starts with "Fixes:".
If the issue is already closed (e.g. cherry-pick) it can add an additional fix 
version (e.g. 5.9.7).

Note: Task-number will be used as before as "this is related to the issue in 
some way".

Cheers,
Frederik



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

Re: [Development] clang-format

[Frederik Gladhorn]

On onsdag 20. juni 2018 13.01.10 CEST Tor Arne Vestbø wrote:
> On 20 Jun 2018, at 12:13, Lars Knoll  wrote:
> 
> > 
> > I can’t see how clang-format will make you jump through any sort of hoops.
> > Creator already has a hook for doing it on file saving time afaik,
> > git-clang-format will clean up your change from the command line.
> 
> Good point, I was imagining it used only to verify style, not to
> auto-format. Still, starting out with a few non-controversial rules would
> be a good thing.

For now we're trying to get the format definition file into qt5 at all.
Once we have a file we agree on (and I'd be happy to see it evolve, it's in 
git, so please just contribute everyone), we can decide how to use it.

I see several things that would make sense.
1) Make it easy to use locally. That is mostly the case, just run:
   $ git clang-format
   And the lines you changed will be reformatted.

2) It's relatively easy to have a commit hook that complains or runs clang-
format for you.

3) Make it part of the sanity bot with a nice message explaining that it's 
possible to use clang-format and ask contributors to use it (with neutral or 
-1 effect).

Cheers,
Frederik
 
> Tor Arne 
> 
> 
> 
> > 
> > Lars
> > 
> > 
> >> On 20 Jun 2018, at 11:52, Tor Arne Vestbø  wrote:
> >> 
> >> How about we also start with only one or two  obvious rules that everyone
> >> agrees on? I don’t want Qt development to turn into Python PEP8 type
> >> rigid rules that makes you jump through a million hoops. If the latter
> >> is the goal here then I’m against enforcing clang-format, and it should
> >> be implemented as a bot that just warns, similar to the current style
> >> bot.
 
> >> - Tor Arne
> >> 
> >> 
> >>> On 20 Jun 2018, at 11:21, André Pönitz  wrote:
> >>> 
> >>> 
>  On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote:
>  
>  
>  
> > On 19 Jun 2018, at 18:19, Ville Voutilainen
> >  wrote:
> > 
> > On 19 June 2018 at 19:13, Philippe  wrote:
> > 
> >>> For the above reasons I'd lean towards not running it globally and
> >>> just using it on new changes.
> >> 
> >> 
> >> +1, based on my clang-format experience on a big application.
> >> 
> >> BTW, keep in mind that you can disable clang-format on code
> >> sections with:
> >> 
> >> // clang-format off // clang-format on
> > 
> > 
> > When I last experienced a large-scale clang-format reformat, it
> > really hurt development during the churn. We should somehow manage
> > to do it during a time when there aren't many pending patches in the
> > pipeline. I'm not concerned about git-blame; that has never been a
> > problem after reformats. However, I do not care about indentation
> > nor do I want to spend time on it either way, it has no actual
> > effect on readability and maintainability of code, and consistency
> > outside the file you're in has never mattered to me one bit.
> > 
> > IOW, I'm not opposed to reformats and auto-checking of clang-format
> > (or even hooking it), but I do not see it as a thing with all that
> > great return-of-investment.
>  
>  
>  It helps in that you do not need to point those things out in code
>  reviews, and that I (and others) won’t even create changes with wrong
>  formatting that I’ll need to fix up later on. It’s part of a larger
>  story, where I would like to get as much automatic checking of changes
>  done before humans start reviewing.
> >>> 
> >>> 
> >>> It's also a cultural thing.
> >>> 
> >>> Quite a few people seem to take less offense from a "Your formatting is
> >>> bad" when the comment comes from a bot than when it comes from a human.
> >>> 
> >>> 
> >>> 
>  One idea could be to introduce this incrementally. Let’s first start
>  off with enforcing it for new changes. Then we run it globally over
>  the code base shortly before Qt 6.0 is being released. At that time
>  merges shouldn’t be as much of a problem (as we’ll probably
>  cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
>  be properly formatted (due to the earlier hook).
> >>> 
> >>> 
> >>> Incrementally sounds good to me.
> >>> 
> >>> Still I am a bit of a fence here. So far I've seen a couple of auto-
> >>> formatting attempts biting back, so I thinl it would help to convince
> >>> me
> >>> to see the kind of changes that would happen first before deciding
> >>> on the global change.
> >>> 
> >>> Andre'
> >>> ___
> >>> 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

Re: [Development] clang-format

[Frederik Gladhorn]

OK, so for now, my take-away from this thread is that we should simply create 
nice commit-hooks that help everyone along. As a next step we can also enhance 
the sanity bot with friendly messages.
I ran clang-format a few times over different parts of the code-base and I 
agree that it sometimes ends up with stuff looking worse. Either use the opt 
out for those parts or live with it.
Not having to debate the format again and again is a big win in my opinion.

Let's move the _clang-format file from qtrepotools to qt5.git:
https://codereview.qt-project.org/#/c/233051/
https://codereview.qt-project.org/#/c/233050/

Cheers,
Frederik

On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote:
> Hi all,
> 
> as part of the closing ceremony of this year's Qt Contributors' Summit we
> agreed to start using clang-format, to have fewer discussions around coding
> style and rather focus on the actual code.
> 
> I have not yet thought about all angles, how to best implement this, here
> are some notes:
> 
> We have a clang-format file in qtrepotools. You can use it today, simply
> make sure it's in any parent directory of the files you are editing. I'd
> actually propose simply moving this into the root directory of qt5.git.
> https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
> 
> If you want to clean one file:
> clang-format -i myfile.cpp/h
> 
> To clean a commit (only modifies the working tree):
> git clang-format
> 
> 
> Getting clang-format seems easy enough:
> On macOS: brew install clang-format
> Linux: install clang-format
> Windows: it comes with normal clang
> 
> Then there is the tooling/workflow perspective. Creator and other IDEs have
> support (you may need to enable the beautifier plugin in about plugins).
> I imagine we add this to the sanity bot ("git clang-format --diff -q" should
> return empty, otherwise post a message).
> 
> Local hooks are basically the same, any ideas how to best set up the git
> hooks appreciated :)
> 
> And then there is the big question when we run it once over the entire
> codebase.
> 
> Cheers,
> 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] clang-format

[Frederik Gladhorn]

On tirsdag 19. juni 2018 17.51.28 CEST Thiago Macieira wrote:
> On Tuesday, 19 June 2018 02:34:09 PDT Lars Knoll wrote:
> > Currently, we only merge from 5.11 to dev, so I hope this won’t be too
> > bad.
> > But we could of course also run the tool over both branches.
> 
> I have right now 149 changes on top of qtbase's dev branch. For something
> that is ostensibly a whitespace change, I will dedicate no more than 1
> minute per change to resolve a conflict or 15 minutes total to rebase my
> branch once it goes in.
> 
> Any change that times out will be dropped. That includes all the Qt 6
> container work, the un-accepted QtDBus updates (which include a
> QDBusConnection::connect taking PMF), a large refactoring of
> QFileSystemEngine that no one has reviewed yet despite being on Gerrit for
> over a year, some work for CBOR and a few other miscellaneous changes.

That should be scriptable afaict, correct me if I'm wrong.

checkout the change before we run clang-format
run clang-format on the changed files
push on top of the formatting change

Cheers,
Frederik






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

[Development] clang-format

[Frederik Gladhorn]

Hi all,

as part of the closing ceremony of this year's Qt Contributors' Summit we 
agreed to start using clang-format, to have fewer discussions around coding 
style and rather focus on the actual code.

I have not yet thought about all angles, how to best implement this, here are 
some notes:

We have a clang-format file in qtrepotools. You can use it today, simply make 
sure it's in any parent directory of the files you are editing. I'd actually 
propose simply moving this into the root directory of qt5.git.
https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format

If you want to clean one file:
clang-format -i myfile.cpp/h

To clean a commit (only modifies the working tree):
git clang-format


Getting clang-format seems easy enough:
On macOS: brew install clang-format
Linux: install clang-format
Windows: it comes with normal clang

Then there is the tooling/workflow perspective. Creator and other IDEs have 
support (you may need to enable the beautifier plugin in about plugins).
I imagine we add this to the sanity bot ("git clang-format --diff -q" should 
return empty, otherwise post a message).

Local hooks are basically the same, any ideas how to best set up the git hooks 
appreciated :)

And then there is the big question when we run it once over the entire 
codebase.

Cheers,
Frederik



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

Re: [Development] Consistently flaky test QTabWidget test

[Frederik Gladhorn]

On onsdag 2. mai 2018 09.29.18 CEST Thiago Macieira wrote:
> 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11
> yesterday resulted in
> 
>  FAIL!  : tst_QTabWidget::paintEventCount() Compared values are not the same
> Actual   (tab2->count): 2
> Expected (1)  : 1
> Loc: [tst_qtabwidget.cpp(573)]
> [on macOS 10.12]
> 
> This test *is* flaky because it succeeded in one of the retries, but
> apparently failed the other 16 runs.
> 
> Can someone take a look?

For anyone investigating, we have a bit of support in analyzing:
https://testresults.qt.io/grafana/d/9/coin-single-test-details?
orgId=1=qt%2Fqtbase=tests%2Fauto%2Fwidgets%2Fwidgets
%2Fqtabwidget=All=5.11=dev
inter=24h

I hope that helps (it pretty clearly shows that it's been a recent 
regression). Thanks Kari for taking care of it :)
This one seems already under control, but generally, let's base things on data 
if we can.

This should give an overview over flaky tests in general:
https://testresults.qt.io/grafana/d/7/coin-flaky-tests

Cheers,
Frederik



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

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Frederik Gladhorn]

On mandag 16. april 2018 11.35.28 CEST Jani Heikkinen wrote:
> Hi!
> 
> Keeping release tags is OK for me. Motivation behind my proposal was to stop
> planning other release dates than FF & final target. Currently we are
> trying to estimate also alpha, beta and RC release dates and it seems to
> cause some delays for us: persons aren't fixing blocker issues or doing the
> test because it seems there is a time to do that later (because e.g RC date
> is planned to be after a month). So if the way to go is to do these
> "releases" immediately when ready it might help us to get fixes in earlier
> and so on also get releases out quicker...

This sounds like it is the real issue. In my opinion, we should have a list of 
"known issues for betas" (does anyone know of a good way of tracking these, so 
that it's obvious and little work?). JIRA? Somewhere else?

I think each beta is for finding more issues (if we consider it necessary), but 
we should not have anything block a beta from going out (OK, maybe if it 
doesn't compile, but how did we end up in such a bad state?). So there is the 
beta with a potentially growing and then shrinking list of release blockers.

This means we may have critical bugs not fixed in the next beta, only in the RC 
latest.
At the same time, I do wonder how strong the argument for more than one beta 
release really is. We should rather offer continuous post-beta snapshots, but 
IMHO we should only ask to test exactly once, during one beta.
If we then trust that we fix the issues that were uncovered, we should move to 
the RC phase, without another beta (beta2/3/4/... contain very few changes 
compared to the first one anyway). There is little value in asking a great 
amount of people to re-test. The bad issues uncovered in the beta can be 
tested using post-beta snapshots, as needed.

The only thing that can be blocked imho is the release candidate. We should 
never have a release candidate that does not include fixes for all known 
issues. The release candidate should then turn into the final release after a 
brief sanity check. There must not be any changes from release candidate to 
release. If it turns out that we really messed up badly, we'll have another RC 
+ release.

I think this would help us get releases out quickly. It would mean, we really 
need to play by our own rules:
after alpha: no more API changes, unless fixing new API. All new features must 
be _complete_, with no known big bugs (or thrown out again). I am certainly 
guilty of breaking this rule in the past and delaying releases...
after beta: no more changes, except for fixes for release blockers
release candidate: no more changes, unless brown paper bag issues are found

Cheers,
Frederik



> 
> But this change doesn't meant we need to stop calling those releases as
> Alpha or Betas so we can continue labeling those as earlier.
> 
> br,
> Jani
> 
> > -Original Message-
> > From: Development  > project.org> On Behalf Of Lars Knoll
> > Sent: maanantai 16. huhtikuuta 2018 10.03
> > To: Simon Hausmann 
> > Cc: Qt development mailing list 
> > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for
> > release
> > process change
> > 
> > Hi,
> > 
> > From a releasing perspective I agree that the set we should update our
> > packages often. We should also stop delivering source only alpha packages,
> > and have binaries from the get go.
> > 
> > But from a user perspective, I agree that it's good and important to put a
> > name to those releases so people know what to expect from them.
> > Snapshots as long as the packages are created from the dev branch, then
> > alpha, beta, RC and final. We could discuss whether we need the alpha
> > label, or whether we can go directly to beta, but I believe that we do
> > need the other tags.
> > 
> > But I do agree with releasing packages as often as possible, and we should
> > have them already before FF from the dev branch (if possible).
> > 
> > So I’d propose to have our packages updated often. But we do keep the
> > ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags.
> > 
> > - Snapshot packages from the dev branch
> > - FF and branching occur together and packages are getting the ‘alpha’ tag
> > - Agree that we should start with the API review immediately.
> > - Beta once API review is done
> > - RC once we have the release branch and all currently known blockers are
> > fixed
> > 
> > That should be pretty close to what Jani described, only that we keep the
> > tags for our users.
> > 
> > Cheers,
> > Lars
> > 
> > > On 16 Apr 2018, at 08:43, Simon Hausmann 
> > 
> > wrote:
> > > Hi,
> > > 
> > > Same here. At first this seemed like a good idea, but it becomes awkward
> > 
> > when you look at it from the dev workflow point of view: After fixing a
> > bug, what is the fix version? Reported in snapshot-24062918 and fixed in
> > 

Re: [Development] Proposing Oliver Wolff as platform maintainer for UWP

[Frederik Gladhorn]

+1

Cheers,
Frederik

(And a big thank you to both Oliver and Maurice for cleaning up all kinds of 
provisioning stuff on Windows lately!)



On mandag 9. april 2018 14.17.34 CEST Maurice Kalinowski wrote:
> Hi,
> 
> As some might have recognized my focus inside the Qt Company has shifted
> from WinRT/UWP towards our Automation related offering. While I still
> review many patches for this platform, my effort in terms of active
> development have significantly reduced.
> 
> Consequently, I would like to propose Oliver Wolff to take over the role as
> platform maintainer. Oliver has been part of the team for years and
> (besides lots of other things) has been taking care of the networking
> parts. In addition to that, he has been "shadow-maintaining" the port over
> the last year, so this would rather reflect reality.
> 
> https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolf
> f%2540qt.io%253E%22,n,z
> 
> BR,
> Maurice
> 
> P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the
> maintainer list, contrary to me when I took it over from Andrew :)
> 
> --
> Maurice Kalinowski
> Principal Software Engineer
> 
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> maurice.kalinow...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> ___
> Development mailing list
> Development@qt-project.org
> 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 -> up again

[Frederik Gladhorn]

I restarted the sanity bot just now, please give it a few minutes to catch up 
on your changes :)

Cheers,
Frederik

On onsdag 4. april 2018 10.28.15 CEST Liang Qi wrote:
> 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] Nominating people from our release team for approver rights

[Frederik Gladhorn]

Hello all,

in 2014 we agreed to make the release team in The Qt Company approvers for the 
Qt Project to enable them to work efficiently.

Since then we had Aapo join the team. Aapo is working hard on improving Coin 
and getting all our changes through CI smoothly. Sadly he doesn't have many 
commits in the public repos.

Since he's been doing a lot of good work on Coin and the QA side of things, 
helping the release team, I'd like to propose him as approver.

Cheers,
Frederik



On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote:
> Hi,
> 
> I’d like to nominate a couple of people from the release team for approver
> rights. They’ve been working for the last 14 month with our release and CI
> infrastructure, and even though many of their contributions are not as
> directly visible (and often aren’t visible in gerrit), they are highly
> important to the project. I believe they all know the approval process
> well, and them being Approvers will also make it easier to get releases
> out in the future.
> 
> The people I’d like to nominate are:
> 
> Tony Sarajärvi
> Simo Fält
> Matti Paaso
> Akseli Salovaara
> Jani Heikkinen
> 
> Cheers,
> Lars
> 
> 
> ___
> 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] Nominating Ville Voutilainen as approver

[Frederik Gladhorn]

+1 he's also getting his hands dirty with flaky tests and making things work in 
general :-)

Cheers,
Frederik



From: Simon Hausmann
Sent: Tuesday, February 27, 10:36
Subject: [Development] Nominating Ville Voutilainen as approver
To: development@qt-project.org


Hi,

I would like to nominate Ville as approver. Due to his work in the GCC project 
he is certainly experienced with strict code reviews. Based on my interaction 
with him I'm convinced that he has successfully demonstrated the same skill set 
during code reviews in Qt.



Simon


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

Re: [Development] Google Summer of Code

[Frederik Gladhorn]

On onsdag 14. februar 2018 12.22.34 CET Benjamin TERRIER wrote:
> 2018-02-13 17:22 GMT+01:00 Thiago Macieira <thiago.macie...@intel.com>:
> > On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn 
wrote:
> > > Hi all,
> > > 
> > > The Qt Project has been accepted as mentor organization for GSoC. Yay!
> > > https://summerofcode.withgoogle.com/organizations/5388456415461376/
> > 
> > That reads "The Qt Company", not "The Qt Project".
> > 
> > > We now should collect ideas for projects that students could work on, we
> > > started here:
> > > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas
> > 
> > Would've been nice to be told we were applying, so we could contribute to
> > the ideas list.
> 
> That's because according to the Qt Project governance model, if the
> mailing list has never been informed
> that the Qt Project was applying, then the Qt project was not applying.
> So it looks to me that the Qt Company applied for the Qt Project.
> Or am I missing something?

Yes. We did, we should have announced it beforehand. Please believe me that 
there was no bad intention, quite the opposite.
The Qt Company will support projects and mentor some, we'd love to have the 
community involved, as usual, just drop me a line and I'll add you to the list 
of mentors. I hope we end up doing a good job and will continue this next year 
in a more coordinated fashion :)

> Anyway that's a great idea, and I like the idea of an IncludeOS port of Qt.
> 
> Is there some decisions already made about the licensing of the
> contributions? Like, are contributions going to be released under
> GPL/LGPL/Commercial license like most of Qt,
> or are they going to be GPL/Commercial only?

As Thiago says, the work needs to follow all the usual procedures of 
contributing to Qt.

Cheers,
Frederik


> 
> Regards,
> 
> Benjamin
> ___
> 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] Google Summer of Code

[Frederik Gladhorn]

Hello Thiago,

I tried to clarify things with my mail. It was a bit of a chance that we got 
in at all, we got the name wrong and probably a ton of other things.
All taken into account, I think it's actually pretty great that we got in and 
I'd rather we prove now that Qt is something students should work on than 
dwell on our beginner mistakes.
I assure you there was no bad intent, just a complete lack of coordination. I 
learned that we had applied the same day I sent the mail.

On tirsdag 13. februar 2018 17.22.36 CET Thiago Macieira wrote:
> On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn 
wrote:
> > Hi all,
> > 
> > The Qt Project has been accepted as mentor organization for GSoC. Yay!
> > https://summerofcode.withgoogle.com/organizations/5388456415461376/
> 
> That reads "The Qt Company", not "The Qt Project".

As mentioned, it was a mistake, coordination and such... I mentioned this at 
the end of my original mail.
https://summerofcode.withgoogle.com/organizations/5388456415461376/ is now 
fixed. Please don't let this stop you from getting involved.

> > We now should collect ideas for projects that students could work on, we
> > started here:
> > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas
> 
> Would've been nice to be told we were applying, so we could contribute to
> the ideas list.

Yes, please do contribute now. There is nothing preventing us from getting a 
great ideas page in place, actually that's currently our main focus, getting 
the page polished and filled with interesting projects. Everyone can add to the 
page, so please do.

Cheers,
Frederik

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

[Development] Google Summer of Code

[Frederik Gladhorn]

Hi all,

The Qt Project has been accepted as mentor organization for GSoC. Yay!
https://summerofcode.withgoogle.com/organizations/5388456415461376/

We now should collect ideas for projects that students could work on, we 
started here:
https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas

For students it's a good idea to start talking to people in areas you are 
interested in already. We have not yet set the criteria for being accepted, 
but I imagine you should at least have pushed a change or two to Qt's 
codereview and have some C++ knowledge (or willingness to learn), depending on 
the task.
http://wiki.qt.io/Qt_Contribution_Guidelines will help you getting started.

Check out KDE's guidelines, many things apply to Qt (both for students and 
mentors):
https://community.kde.org/GSoC

I'd like to invite everyone to join #qt-gsoc on freenode.
Ask questions about procedure in #qt-gsoc, programming questions then in #qt-
labs on IRC/freenode. This mailing list is also a good place to discuss about 
potential work this summer.

People that have been active in developing Qt can of course be mentors, let me 
know if you want to be part of the mentor team, signing up for mentoring is 
not a commitment yet. Note that you cannot be mentor and student at the same 
time. We will aim to have at least two mentors for each project and that 
mentoring does take time and commitment, it's not an easy task (not to 
discourage you, the more mentors we have, the better).

The general overview page for Qt GSoC is here:
https://wiki.qt.io/Google_Summer_of_Code/2018

Right now the organization page for GSoC shows "The Qt Company", which is a 
mistake we made when applying for the program. It of course should be the "Qt 
Project".

This is the first time we'll participate in GSoC, so I don't expect us to get 
too many slots, we'll find out as we go, I do hope we'll have some great 
applications and get interesting things into Qt.

Cheers,
Frederik

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

Re: [Development] Deprecation of Qt Quick Controls 1

[Frederik Gladhorn]

Thanks for the feedback :)

Seems like this was a good point to send the mail and we became aware that 
many of you are struggling with the ComboBoxes in Controls 2. Improving that 
makes a lot of sense for us then.

Note that we are not going to make the module magically disappear for the 
moment, it will still be part of Qt releases for the time being.
This was to check what we have left to do to allow a happy transition and 
prepare and nudge everyone else to move to Controls 2.

Cheers,
Frederik


On onsdag 7. februar 2018 13.48.21 CET Frederik Gladhorn wrote:
> Hi all,
> 
> It should come as no big surprise that we are not working much on Qt Quick
> Controls 1. After some discussions inside The Qt Company, we concluded that
> it would make sense to clarify the situation. We see the value Controls 1
> provides - more platform native styling - but it comes at a high price.
> 
> Performance is very problematic with the module and we now offer more modern
> styles in Controls 2. In addition customizing the styles in Controls 2 is
> possible in different ways. There is the image based style that is
> especially accessible to graphical designers. There is the general styling
> that has become really cheap now (thanks to the deferred execution
> patches), so replacing parts of the ready-made controls does come at no
> cost. Finally writing a completely custom style is entirely possible, using
> the logic of Controls 2 as building blocks. In fact I see Controls 2 as
> being part of Qt Quick, the part that has been missing for a long time and
> that completes the story to make developing applications with Qt Quick
> easy. With the recent updates to the Qt Quick Designer in Qt Creator and
> additions to make Controls 2 more desktop friendly for modern applications,
> I'd recommend everyone to move over.
> 
> Next to that we have picked up Qt Widgets lately again and fixes are making
> their way into the module. For applications that need to look and behave
> like traditional desktop applications, this is an alternative.
> 
> As you can see, the effort is currently split and we'd like to reduce the
> attention to the two big areas - Widgets and Quick with Controls 2. This
> means we will spend even less time on Controls 1, where we'll only fix
> critical issues in the future.
> 
> As always, feedback welcome :)
> 
> Cheers,
> Frederik


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

[Development] Deprecation of Qt Quick Controls 1

[Frederik Gladhorn]

Hi all,

It should come as no big surprise that we are not working much on Qt Quick 
Controls 1.
After some discussions inside The Qt Company, we concluded that it would make 
sense to clarify the situation.
We see the value Controls 1 provides - more platform native styling - but it 
comes at a high price.

Performance is very problematic with the module and we now offer more modern 
styles in Controls 2.
In addition customizing the styles in Controls 2 is possible in different ways. 
There is the image based style that is especially accessible to graphical 
designers. There is the general styling that has become really cheap now 
(thanks to the deferred execution patches), so replacing parts of the 
ready-made controls does come at no cost. Finally writing a completely custom 
style is entirely possible, using the logic of Controls 2 as building blocks. 
In fact I see Controls 2 as being part of Qt Quick, the part that has been 
missing for a long time and that completes the story to make developing 
applications with Qt Quick easy. With the recent updates to the Qt Quick 
Designer in Qt Creator and additions to make Controls 2 more desktop friendly 
for modern applications, I'd recommend everyone to move over.

Next to that we have picked up Qt Widgets lately again and fixes are making 
their way into the module. For applications that need to look and behave like 
traditional desktop applications, this is an alternative.

As you can see, the effort is currently split and we'd like to reduce the 
attention to the two big areas - Widgets and Quick with Controls 2. This means 
we will spend even less time on Controls 1, where we'll only fix critical 
issues in the future.

As always, feedback welcome :)

Cheers,
Frederik

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

[Development] QUIP 101: Contributing to Qt

[Frederik Gladhorn]

Hi all,

I just pushed a QUIP that I hope captures some of our philosophy and ideas 
behind the Qt Project when it comes to contributing to Qt. I didn't discuss it 
with many people yet, so it may be controversial. I'd like to get feedback of 
course :)

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

Cheers,
Frederik

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

Re: [Development] Nominating Adam Treat for approver

[Frederik Gladhorn]

On mandag 15. januar 2018 14.52.29 CET Simon Hausmann wrote:
> Hi,
> 
> 
> I would like to nominate Adam for approver status. He has been developing
> with Qt for more than a decade and has been working on Qt and Qt 3D studio
> full time for about a year. I fully trust him to review changes thoroughly
> and reject stuff that looks fishy :)

+1, I've had great discussions with Adam and he knows his way around Qt :)

Cheers,
Frederik

> 
> 
> 
> 
> Simon


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

Re: [Development] QML and Qt Quick versioning of our modules

[Frederik Gladhorn]

Hi,

I'll start turning this thread into a QUIP here (currently empty placeholder 
commit):
https://codereview.qt-project.org/#/c/215625/

I'll update the list when I have written something. In the mean time I'd like 
to ask for this to become QUIP #99 and hereby reserve the number.

Cheers,
Frederik

On torsdag 7. desember 2017 14.53.06 CET Frederik Gladhorn wrote:
> Hi all,
> 
> I've lately been discussing with a few people in The Qt Company about our
> versioning.
> Historically it was a good idea to not couple Qt Quick too tightly to
> general Qt releases. There were quite some constraints and added
> flexibility was nice. Qt Quick has matured a lot though, so I think it's
> time to consider making everyone's lives easier by cleaning up our version
> chaos.
> See also J-P's previous mail here: http://lists.qt-project.org/pipermail/
> development/2015-September/023200.html
> 
> Examples are the version section in here:
> https://doc.qt.io/qt-5/qtquickcontrols2-index.html
> And a general confusion around which version does what.
> Since we so far don't keep copies of old functions around (as far as I'm
> aware at least), I don't think there's a huge value in the versioning
> system in the first place.
> It only gives one important guarantee: if you added a property/type/name and
> import a defined version, you don't suddenly get conflicts because we
> introduced the same name.
> 
> Some modules started to copy the Qt version, e.g. Multimedia, that's pretty
> easy to remember and a good start in my opinion.
> 
> I have several ideas and I'm unsure how hard they would be to implement, so
> I'll list things from easy to hard.
> 
> 1) sync minor versions to Qt release version:
> For Qt 5.11, we would provide QtQuick.Controls 2.11
> This way, the challenge for the user is only to find out if it's version 1,
> 2 or 5.
> 
> 2) Make the minor version import optional and we pick the lastest. This
> should be optional to prevent the name clashes described above and shifts
> the risk to the user.
> In practice I'd expect this to be pretty safe.
> import QtQuick.Controls 2 would then give the latest version available.
> 
> 3) Make even the major version optional and we'd pick up the latest version.
> import QtQuick.Controls would give version 2.11 with Qt 5.11.
> 
> I don't see us releasing most of the QML/Qt Quick modules independent of the
> rest of Qt any time soon, so I hope this will make things easier for
> everyone. I'm sure there are even better ideas out there, this is just my
> version and current thinking, I hope for constructive suggestions :)
> 
> In the end I want this to be easier for Qt users and also to lessen our
> maintenance burden and the need to look up versions, explain the scheme and
> reduce the confusion.
> 
> Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to
> help registering the current versions already.
> 
> Cheers,
> 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] Weird issue in CI

[Frederik Gladhorn]

On torsdag 21. desember 2017 10.46.20 CET Konstantin Tokarev wrote:
> > On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote:
> >> I'm repeatedly getting this error:
> >> 
> >> Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1':
> >> Failed repeatedly to launch build/test agent
> > 
> > This means it never actually did any work because it either didn't get a
> > VM or when acquiring one, it didn't manage to communicate with it (we
> > launch a program on the VMs = the "agent", which calls home once the
> > machine is up and running). I'll improve the error message at least.
> 
> Main problem is not error text, but fact that on I restage I get the same
> error again and again (for same or different VM image)

Indeed, let me quote myself:
> > This points to a bug in Coin or the infrastructure below it. Someone who
> > has access needs to investigate.

There was nothing you could do, it was due to a filesystem claiming it had 
space while it didn't. If you get the same message repeatedly, it points at 
underlying problems and restaging is probably pointless.

Cheers,
Frederik


> 
> >> Details:
> >> https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851
> >> 
> >> No log exist.
> > 
> > We only show logs when anything happens on a VM (=agent). Since it never
> > got that far there is no log, we only have our general logs for all of
> > Coin to look at.
> > 
> > This points to a bug in Coin or the infrastructure below it. Someone who
> > has access needs to investigate.
> > 
> > Cheers,
> > Frederik


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

Re: [Development] Reporting errors for powershell scripts executed by Coin

[Frederik Gladhorn]

On fredag 22. desember 2017 09.17.47 CET Tony Sarajärvi wrote:
> Hi
> 
> We ignore the results of PS1 scripts because A) We have bad scripts that try
> to remove folders that don't exists anymore (should be cleaned) and B) as
> your example said, if we enabled enforcing of them now, things would break
> apart (fix needed as well )

I would consider this a major bug. We never intended to ignore errors in the 
PS scripts and shouldn't.
https://bugreports.qt.io/browse/QTQAINFRA-1178 considered this a P0 and should 
be re-opened if we have this happening again.

Cheers,
Frederik


 
> -T
> 
> -Original Message-
> From: Development
> [mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf
> Of Konstantin Tokarev
 Sent: torstai 21. joulukuuta 2017 20.37
> To: development@qt-project.org
> Subject: [Development] Reporting errors for powershell scripts executed by
> Coin
 
> Hi all,
> 
> AFAIU, some time ago Coin considered ps1 script to be failed its exit code
> was non-null (e.g, Exit(1) certainly aborted further provisioning
> process).
 
> Now I see that Exit(1) is ignored (see [1]). What is the correct way now,
> throw exception?
 
> [1]
> https://testresults.qt.io/coin/api/results/provisioning/qtci-windows-10-x86
> _64-10-f8e8db/provision_1513869138/log.txt.gz
 
> Words "conan exited with code 1" are printed before script does Exit(1)
> 
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] Weird issue in CI

[Frederik Gladhorn]

On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote:
> I'm repeatedly getting this error:
> 
>  Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1':
>  Failed repeatedly to launch build/test agent

This means it never actually did any work because it either didn't get a VM or 
when acquiring one, it didn't manage to communicate with it (we launch a 
program on the VMs = the "agent", which calls home once the machine is up and 
running). I'll improve the error message at least.

>  Details:
> https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851
> 
> No log exist.

We only show logs when anything happens on a VM (=agent). Since it never got 
that far there is no log, we only have our general logs for all of Coin to 
look at.

This points to a bug in Coin or the infrastructure below it. Someone who has 
access needs to investigate.

Cheers,
Frederik

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

Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards

[Frederik Gladhorn]

On fredag 15. desember 2017 20.04.33 CET Tuukka Turunen wrote:
> Hi,
> 
> 
> I propose to remove support for QNX 6.6 from Qt 5.11 onwards.

Yes please, it has been a bit of a trouble maker every once in a while :)
For example not needing to patch a header file on the platform is a good thing.

Cheers,
Frederik


> 
> 
> Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we
> would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be
> supported with Qt 5.9 LTS and Qt 5.10.
> 
> 
> Based on my experience QNX 7.0 is a better choice for new projects than QNX
> 6.6. It has, for example, better C++11 support, 64 bit support and improved
> graphics support.
> 
> 
> I have discussed the topic with James McDonnell (QNX platform maintainer) as
> well as QNX product management and they agree that it is better to focus
> into improving QNX 7.0 support with upcoming Qt releases rather that
> splitting the effort between QNX 6.6 and 7.0.
> 
> 
> Yours,
> 
> 
>   Tuukka


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

Re: [Development] QT printing via CUPS (advanced printing dalog box missing)

[Frederik Gladhorn]

Thanks for picking this up and working on it :)

Frederik

On onsdag 6. desember 2017 15.35.44 CET Albert Astals Cid wrote:
> El dilluns, 4 de desembre de 2017, a les 15:16:16 CET, Albert Astals Cid va
> 
> escriure:
> > El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va
> > 
> > escriure:
> > > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote:
> > > > This bug has been reported on QT ( see
> > > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a
> > > > year and half now, the bug status is still *reported* and the
> > > > resolution
> > > > *unknown*.
> > > > 
> > > > I am sorry to post this information here, but we are many users
> > > > affected
> > > > by this bug and we are desperate because we don't have any feed back
> > > > from QT. Is there anybody working on it ?
> > > 
> > > No, there is not.
> > > 
> > > The module is currently orphan, with no maintainer.
> > 
> > Reviews more than welcome
> > 
> > https://codereview.qt-project.org/#/c/213391/
> > https://codereview.qt-project.org/#/c/213390/
> > https://codereview.qt-project.org/#/c/213389/
> > https://codereview.qt-project.org/#/c/213388/
> > https://codereview.qt-project.org/#/c/213387/
> > https://codereview.qt-project.org/#/c/213386/
> > https://codereview.qt-project.org/#/c/213385/
> > https://codereview.qt-project.org/#/c/213384/
> > https://codereview.qt-project.org/#/c/213383/
> 
> and some more (more regarding to default values than to the advanced tabs
> itself)
> 
> https://codereview.qt-project.org/#/c/213483/
> https://codereview.qt-project.org/#/c/213575/
> https://codereview.qt-project.org/#/c/213580/
> https://codereview.qt-project.org/#/c/213589/
> https://codereview.qt-project.org/#/c/213598/
> https://codereview.qt-project.org/#/c/213661/
> https://codereview.qt-project.org/#/c/213677/
> 
> Cheers,
>   Albert
> 
> > Cheers,
> > 
> >   Albert


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

[Development] QML and Qt Quick versioning of our modules

[Frederik Gladhorn]

Hi all,

I've lately been discussing with a few people in The Qt Company about our 
versioning.
Historically it was a good idea to not couple Qt Quick too tightly to general 
Qt releases. There were quite some constraints and added flexibility was nice.
Qt Quick has matured a lot though, so I think it's time to consider making 
everyone's lives easier by cleaning up our version chaos.
See also J-P's previous mail here: http://lists.qt-project.org/pipermail/
development/2015-September/023200.html

Examples are the version section in here:
https://doc.qt.io/qt-5/qtquickcontrols2-index.html
And a general confusion around which version does what.
Since we so far don't keep copies of old functions around (as far as I'm aware 
at least), I don't think there's a huge value in the versioning system in the 
first place.
It only gives one important guarantee: if you added a property/type/name and 
import a defined version, you don't suddenly get conflicts because we 
introduced 
the same name.

Some modules started to copy the Qt version, e.g. Multimedia, that's pretty 
easy to remember and a good start in my opinion.

I have several ideas and I'm unsure how hard they would be to implement, so 
I'll list things from easy to hard.

1) sync minor versions to Qt release version:
For Qt 5.11, we would provide QtQuick.Controls 2.11
This way, the challenge for the user is only to find out if it's version 1, 2 
or 5.

2) Make the minor version import optional and we pick the lastest. This should 
be optional to prevent the name clashes described above and shifts the risk to 
the user.
In practice I'd expect this to be pretty safe.
import QtQuick.Controls 2 would then give the latest version available.

3) Make even the major version optional and we'd pick up the latest version.
import QtQuick.Controls would give version 2.11 with Qt 5.11.

I don't see us releasing most of the QML/Qt Quick modules independent of the 
rest of Qt any time soon, so I hope this will make things easier for everyone.
I'm sure there are even better ideas out there, this is just my version and 
current thinking, I hope for constructive suggestions :)

In the end I want this to be easier for Qt users and also to lessen our 
maintenance burden and the need to look up versions, explain the scheme and 
reduce the confusion.

Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to 
help registering the current versions already.

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

[Development] Continuous Integration issues - Coin temporarily down

[Frederik Gladhorn]

Hi all,


we've had a bunch of unfortunate small things piling up, so sadly Coin is down 
right now. I expect it to be up tomorrow (so in roughly 10 hours from now) 
assuming everything now goes smooth.


We use local disks to cache VMs running in our Open Nebula instance and found 
that the machines over time fill up the cache (their leftovers should be 
removed, but that seems to not happen under some circumstances). So we had to 
cleanup, but have been struggling with our DNS setup, the new machine to take 
over didn't want to show up on the network for a while. All of this lead to 
more delays that I would have liked, so it basically cost us a day, sorry :-(


Don't give up yet though, we've lately made more and more progress in 
monitoring the whole system and have a bigger focus inside The Qt Company to 
get the infrastructure in place and flaky tests more under control so that 
hopefully contributing to Qt will be more fun. More on that later.


Cheers,

Frederik

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

Re: [Development] Review request

[Frederik Gladhorn]

Hi,

I just moved the changes to dev. They fix P2s which is great, but in my opinion 
we should target dev by default. If there is agreement that they should go to 
other branches, we can move them again.

Cheers,
Frederik


On søndag 29. oktober 2017 20.45.53 CET Thiago Macieira wrote:
> On Sunday, 29 October 2017 11:52:02 PDT Alberto Mardegan wrote:
> > Hi there!
> > 
> >   I've got a few merge proposals which were recently closed by the Qt
> > 
> > cleanup bot due to lack of activity; I've reopened them and ping a few
> > people, but to no avail.
> > All but one are tiny, and I would appreciate if someone could spend a
> > couple of minutes to give the final +2 or to advise about moving them to
> > a different release (I guess that at least the one targeting 5.8 should
> > probably be moved to 5.9, given that 5.8 is not an LTS):
> > 
> > 
> > https://codereview.qt-project.org/#/q/owner:mardy%2540users.sourceforge.ne
> > t+ status:open,n,z
> 
> Corrected URL:
> https://codereview.qt-project.org/#/q/owner:mardy%40users.sourceforge.net
> +status:open,n,z
> 
> You double-encoded the '@'.
> 
> I wish I could help in the reviews, but those are not things I understand at
> all. But I can give this advice: the three changes targetting pre-5.9 need
> to be updated. All three should be retargetted at 5.9.
> 
> If any of them are P1 or P2, they can later be backported to 5.6. But they
> need to happen in 5.9 first.


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

Re: [Development] Needing another advise using git

[Frederik Gladhorn]

On onsdag 4. oktober 2017 19.28.43 CEST Daniel Savi wrote:
> Thank you all for the helpful comments on my previous message.
> 
> I think that I have now managed to amend my changes into one commit and
> may understand how to react on comments.
> 
> While amending my commits I must somehow have pushed another commit
> again that is not from me at all. It is this one:
> https://codereview.qt-project.org/#/c/207639/
> 
> I certainly did not intend to push this one. How should I proceed to
> delete this commit from my changes?

You should just abandon the commit that was accidentally pushed (to avoid 
confusion I just did). I think this happens to most of use at some point in 
time (I managed to push a huge series once, several people got confused, 
including me). Ideally don't rebase changes unless needed and just work on top 
of some branch. When rebasing is needed, do the rebase without further changes 
and comment on that in gerrit to let reviewers know. Then push further changes 
in a separate commit. This dance is only needed when changes that were merged 
conflict with your change.

The dependencies shown in gerrit do not matter on a practical level, they are 
only meant for people to be able to follow through series of changes, but in 
the end the only important thing is whether a cherry-pick of a comment will 
succeed or not.

In other words, now it shows your comment with a dependency that is bogus (the 
abandoned change) but that has no practical implications and should just be 
ignored by reviewers.

@all:
Since there seems to be a lot of confusion around this: gerrit only shows the 
state of the parent commit. When pushing two commits that depend on each other 
and the first one is merged, the second one will by necessity show that it's 
dependency will have been cherry-picked. Any cherry-pick changes the commit 
since it includes the date (and the parent commit potentially changes). This 
is fine. It's unfortunate that our gerrit version shows it in big and red, but 
don't be scared by that. The only thing that matters (you can verify this at 
home with your own git checkout) is that the cherry-pick succeeds.

Cheers,
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] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Frederik Gladhorn]

I'm a bit split here, let's try to find some middle ground :)

I do think that we should always run with accessibility enabled and we don't 
do that for a reason.
One thing to fix for linux accessibility is listening to the change signal on 
for a11y being enabled or not. If I recall correctly listening to property 
changes on dbus is not implemented in Qt since it's impossible to know if 
there are any listeners to these change signals, Thiago knows the details I 
think.

The next thing is to make sure we don't actually send the keyboard and mouse 
events when not needed (pure insanity anyway, we should have a sound 
approach...). For the time being sending all of these events over dbus is the 
only way to make Orca happy and thus the only way to make applications behave 
somewhat acceptable for blind users. Thinking about the code gives me 
nightmares though and I'd support anyone looking at it and making sure we 
don't overdo the sending of events.

And then Allan is right, by setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON you ask 
for it. All the stuff unconditionally. Please don't, why do you need it in the 
first place?
Maybe it's time to sit down and create a somewhat defined way when it should be 
enabled? Right now Qt is trying to emulate Gnome's way, except since we don't 
listen to the change signal, we never dynamically enable/disable a11y. The 
code is there, it's just actually reacting to the notification that's missing.

Cheers,
Frederik



On søndag 3. september 2017 19.13.38 CEST Allan Sandfeld Jensen wrote:
> On Sonntag, 3. September 2017 18:15:15 CEST Samuel Thibault wrote:
> > On the long run, it really should.  Just hiding issues is not the way
> > forward :)
> > 
> > Also, note that if the performance is so bad, it means something *needs*
> > to be fixed, otherwise blind users will get the bad performance, and
> > nobody will be there to fix it, because nobody notices it except blind
> > users, who are left with little hope to fix it by themselves.
> 
> It is not a issue or a bug. The performance impact comes from sending
> everything the mouse hovers over to the accessibility framework (for
> instance to be spoken aloud), when there is not any accessibility tools
> running.
> 
> You are deliberately crippling Qt to always send dbus events even when no
> one is listening.
> 
> Note the performance impact is the same in all applications regardless of
> framework. Running accessibility tools has a substantional performance cost
> on mouse movements, but a mouse rendered or text scrolling at 60 fps is
> completely pointless to blind people, but rather important to everybody
> else.
> 
> 'Allan
> ___
> 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] Adding Qt CoAP

[Frederik Gladhorn]

OK, I'll create the repository, we can still merge several projects later as 
seen fit.

Cheers,
Frederik


On fredag 1. september 2017 14.06.23 CEST Maurice Kalinowski wrote:
> Hi everyone,
> 
> Most of you might have noticed the IoT related discussion happening on this
> mailing list. If not, check here in the archive:
> http://lists.qt-project.org/pipermail/development/2017-August/030723.html
> 
> One of the items mentioned has been CoAP and that it would make a great
> addition to Qt. Interestingly, there has been discussions between the Qt
> Company and Witekio about exactly this topic. Thanks to the people at
> Witekio these resulted in actual code already available to get reviewed. To
> avoid any duplicate effort and have everyone participating as early as
> possible a new repository is needed.
> 
> Name of the project: Qt CoAP
> 
> Responsible person:
> Cedric Amarger
> Gerrit user/email: Cedric Amarger 
> Desired repository name: qtcoap
> 
> For now, I will leave any technical detail to Cedric.
> 
> BR,
> Maurice
> ___
> 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 infrastructure changes

[Frederik Gladhorn]

Hello :)

One day late, we're attempting to switch now. For a short while things will 
take more time (we're so to speak warming up the caches right now), but 
hopefully things will be progressing as normal again.

If you see completely weird behavior, we're of course happy to hear about it.

Cheers,
Frederik

On mandag 31. juli 2017 15.19.00 CEST Frederik Gladhorn wrote:
> Hi all,
> 
> this is mostly for your information. On Wednesday this week (most likely)
> we're making changes to Coin, potentially leading to some interruptions in
> integrations.
> 
> The longer version:
> 
> We've been working towards replacing the underlying virtualization layer in
> our Continuous Integration infrastructure and have now reached a point where
> we're ready (as ready as we'll get at least) to switch over from VSphere to
> OpenNebula. There are a bunch of advantages (not least that we can actually
> debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin
> easier, ...).
> 
> This will also be the point at which we start to use some of the new
> hardware that The Qt Company has been purchasing and getting ready, so
> things will initially be at the same speed and eventually much faster.
> 
> We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some
> merges, hopefully we'll get it working really soon now.
> 
> Hopefully the process is: stop the system; change branch; restart and things
> will work. I would expect some hickups when we scale up and run in
> production mode, so bear with us and report issues, we'll eventually be
> better off, once things are in shape.
> 
> Cheers,
> 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] Coin infrastructure changes

[Frederik Gladhorn]

On mandag 31. juli 2017 15.24.57 CEST Laszlo Agocs wrote:
> Hi,
> 
> Are we sure that the week before the 5.10 feature freeze date is really the
> best time to do this?

Yes and no. There clearly is no good time. The longer we wait, the more 
trouble we'll have. The change is needed to take fresh new hardware into use 
and move forward. Right now things are still comparatively calm as many people 
were on vacation and are only now comming back. We'd have liked to be faster, 
but only now feel that it would be responsible to switch.

The current issues (that are seemingly still ongoing) are by the way the old 
system falling apart, seems like it wants to support us moving on. We haven't 
changed anything yet (and it will probably be Friday before we feel that we're 
finally ready).

Cheers,
Frederik


> 
> Cheers,
> Laszlo
> 
> -Original Message-
> From: Development
> [mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of
> Frederik Gladhorn Sent: mandag 31. juli 2017 15.19
> To: development@qt-project.org
> Subject: [Development] Coin infrastructure changes
> 
> Hi all,
> 
> this is mostly for your information. On Wednesday this week (most likely)
> we're making changes to Coin, potentially leading to some interruptions in
> integrations.
> 
> The longer version:
> 
> We've been working towards replacing the underlying virtualization layer in
> our Continuous Integration infrastructure and have now reached a point
> where we're ready (as ready as we'll get at least) to switch over from
> VSphere to OpenNebula. There are a bunch of advantages (not least that we
> can actually debug issues in OpenNebula/KVM, it'll make the scheduling code
> in Coin easier, ...).
> 
> This will also be the point at which we start to use some of the new
> hardware that The Qt Company has been purchasing and getting ready, so
> things will initially be at the same speed and eventually much faster.
> 
> We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some
> merges, hopefully we'll get it working really soon now.
> 
> Hopefully the process is: stop the system; change branch; restart and things
> will work. I would expect some hickups when we scale up and run in
> production mode, so bear with us and report issues, we'll eventually be
> better off, once things are in shape.
> 
> Cheers,
> 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

[Development] Coin infrastructure changes

[Frederik Gladhorn]

Hi all,

this is mostly for your information. On Wednesday this week (most likely) 
we're making changes to Coin, potentially leading to some interruptions in 
integrations.

The longer version:

We've been working towards replacing the underlying virtualization layer in 
our Continuous Integration infrastructure and have now reached a point where 
we're ready (as ready as we'll get at least) to switch over from VSphere to 
OpenNebula. There are a bunch of advantages (not least that we can actually 
debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, 
...).

This will also be the point at which we start to use some of the new hardware 
that The Qt Company has been purchasing and getting ready, so things will 
initially be at the same speed and eventually much faster.

We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some 
merges, hopefully we'll get it working really soon now.

Hopefully the process is: stop the system; change branch; restart and things 
will work. I would expect some hickups when we scale up and run in production 
mode, so bear with us and report issues, we'll eventually be better off, once 
things are in shape.

Cheers,
Frederik

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

Re: [Development] Widgets maintainers

[Frederik Gladhorn]

Hello all, hello Marc,

First of all, thank you very much for taking care of the widgets module and 
working to get bugs under control.

We've been talking inside The Qt Company about the widgets module a lot 
lately, since we do see it as a very important part of Qt, which doesn't 
receive as much marketing and highlighting as it deserves. For traditional 
UIs, widgets are certainly a viable and good building block.

While we don't anticipate huge changes in the module, we will keep on updating 
the styles where it makes sense and take bugs serious. Since it's also a big 
chunk of a module, we'd like to propse a team of maintainers, to make it 
easier on everyone.

Our proposal is:
Richard Gustavsen as overall maintainer
Gabriel de Dietrich for styles
Jan-Arve Sæther for layouts
Eskil Abrahamsen-Blomfeldt for all text related things
Andreas Aardal Hanssen for graphicsview

Item Views is open and would fall to Richard for now, but if someone is 
interested in helping out more with it, that's certainly appreciated.

Cheers,
Frederik


On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote:
> Hi all,
> 
> KDAB is handing back widgets maintenance, which means that I'm stepping
> down as widgets maintainer. The focus of KDAB contributions to Qt is
> clearly elsewhere these days (Qt3D, Core, tooling), and the module
> deserves more focus than it has seen lately.
> 
> To this end, Lars has assembled a team(!) of proposed widgets
> (sub)maintainers that we as KDAB and I personally fully support as
> successors.
> 
> In Lars' absence, I'll leave it to Frederik to introduce them to you in
> detail (as if introduction was needed...).
> 
> Thanks,
> Marc
> 
> ___
> 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] Examples and Demos in qtdoc

[Frederik Gladhorn]

Hi all,

We recently had a discussion in the Qt Company about how we can improve the 
first use experience of Qt and one important aspect are the examples and demos.

We have a lot of examples that are limited by the Qt module they live in, for 
example not making use of ready made buttons in Qt Quick. To allow examples to 
use any Qt module while keeping the build system clean (no cyclic dependencies 
between modules), I'd like to propose using the qtdoc module to gather fresh 
and beautiful examples.

We currently have a few bigger examples already that would fit this category 
and plan to invest more into good looking nice and welcoming examples to give 
new Qt users a positive first impression.

Of course we could create a new repo, but considering that we have an existing 
repo which did contain the demo launcher previously and which is ready to be 
used, I'd propse going with it, while the name is not perfect. It's already 
part of the infrastructure and qt5.git, so this seems like an easy way to go 
forward.

Cheers,
Frederik

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

Re: [Development] Stepping down as QtDBus maintainer

[Frederik Gladhorn]

Hello Thiago,

Thanks a lot for all the great work on QtDBus!

Cheers,
Frederik

On onsdag 17. mai 2017 09.19.13 CEST Thiago Macieira wrote:
> With https://codereview.qt-project.org/194893 getting integrated, this
> signals my inability to keep QtDBus working for 4 minor releases in a row
> (5.6 through 5.9, inclusive). Obviously, the patch that this change
> reverted is required and it is the only way I've supported QtDBus in the
> last 1½ years, but we don't seem to be able to make it work.
> 
> Since I am unable to fulfill my duties as maintainer, I am stepping down and
> opening the way up for someone else.
> 
> Good luck.
> 
> I've just abandoned all my pending changes related to QtDBus.
Isn't that a bit premature? Maybe someone could use these as inspiration. I'd 
like to see us (as in The Qt Project) be more flexible when it comes to 
ownership of patches - maybe someone feels inspired to take over some of the 
work that has been started and expand on it.

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