Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Jani Heikkinen]

Hi!

It is time to create initial changes files for Qt 5.13.0. Unfortunately it 
seems we didn't manage to conclude this thread & make the decision which script 
is used to generate those. 
For us it is same; we just run the script & push initial ones in gerrit. So 
which one we should use at this time? Should we just try the new one to see 
what kind of problems and complains it will generate?

br,
Jani


From: Development  on behalf of Edward 
Welbourne 
Sent: Wednesday, April 3, 2019 12:32 PM
To: Alexandru Croitor
Cc: development@qt-project.org
Subject: Re: [Development] Switching from create_changelog.pl to 
createchangelog for change log generation

Alexandru Croitor (2 April 2019 14:02)
>> Just to throw some wood into the fire, because it's that kind of day,
>> technically we don't require Python or Go to build qtbase, yet we
>> require Perl. Hence +1 for using the perl script, because we need Perl
>> anyway : P

I note that the createchangelog script is not required to build qtbase.
Nor are the various scripts under qtbase/util/.
Survey of what these use:

C++/Qt (yay):
accessibilityinspector/
aglfn/ - Adobe Glyph List
corelib/qurl-generateTLDs/ (public suffix list)
glgen/ - Khronos OpenGL-related classes
lexgen/
plugintest/
unicode/
xkbdatagen/
gradientgen/ (also uses node.js) - QGradient presets

perl:
includemocs/ (no docs)
x86simdgen/

python:
edid/ - VendorTable
local_database/ - misnamed: locale_database

bash:
harfbuzz/

I have no clue:
integrity/qt.bod - whatever that may be (no docs)
Vaguely resembles JSON or QML.
Seems to be some kind of config.
For something.

On 2. Apr 2019, at 17:43, Edward Welbourne  wrote:
> That sounds a lot like you just volunteered to maintain and review perl
> scripts.  As one of those currently stuck doing so (mainly because
> few others will touch perl with a ten foot pole) I'd gladly replace all
> our perl infrastructure with python and replace the perl dependency.

Alexandru Croitor (2 April 2019 18:12) replied:
> Unfortunately I have minimal knowledge of Perl. But adding tools
> one-by-one in different languages doesn't seem to me the right
> solution either (from a maintenance perspective).

If we get too many different languages, that could be a problem, yes.
On the other hand, evolving is good and some tools are better for
particular jobs than others.  I'm more concerned about tools having no
documentation of how to use them or what they're for (which I have run
into repeatedly - aside from the util/ things with no docs, several have
no more doc than a usage message and at least two only have docs because
I added them after I'd worked out how to use them in order to do so).

It would probably be a good idea to have a "permitted list" of languages
in which dev-related tools can be included in our source tree; and I
think it's pretty sensible to include
* python - we even have a team working on Qt for it
* go - Coin is written in it

If anything I'd leave off perl (and start porting scripts away from it)
because there are too few developers in this community willing to touch
it with a ten foot pole - and scarcely any that actively like working
in it.  (FTR: I'd far sooner review or hack on a python script than a
perl script; but I end up being maintainer and reviewer for perl scripts
because I don't actually refuse and can make sense of perl.)

As for having "minimal knowledge of Perl", if it were a nice language to
work in I'd just encourage you to learn - but I'm not going to do that
to you, as I'd sooner port the existing infrastructure away from it.
One can write nice maintainable perl, but this isn't industry-standard
practice and I do not like maintaining what is,

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] Switching from create_changelog.pl to createchangelog for change log generation

[Edward Welbourne]

Alexandru Croitor (2 April 2019 14:02)
>> Just to throw some wood into the fire, because it's that kind of day,
>> technically we don't require Python or Go to build qtbase, yet we
>> require Perl. Hence +1 for using the perl script, because we need Perl
>> anyway : P

I note that the createchangelog script is not required to build qtbase.
Nor are the various scripts under qtbase/util/.
Survey of what these use:

C++/Qt (yay):
accessibilityinspector/
aglfn/ - Adobe Glyph List
corelib/qurl-generateTLDs/ (public suffix list)
glgen/ - Khronos OpenGL-related classes
lexgen/
plugintest/
unicode/
xkbdatagen/
gradientgen/ (also uses node.js) - QGradient presets 

perl:
includemocs/ (no docs)
x86simdgen/

python:
edid/ - VendorTable
local_database/ - misnamed: locale_database

bash:
harfbuzz/

I have no clue:
integrity/qt.bod - whatever that may be (no docs)
Vaguely resembles JSON or QML.
Seems to be some kind of config.
For something.

On 2. Apr 2019, at 17:43, Edward Welbourne  wrote:
> That sounds a lot like you just volunteered to maintain and review perl
> scripts.  As one of those currently stuck doing so (mainly because
> few others will touch perl with a ten foot pole) I'd gladly replace all
> our perl infrastructure with python and replace the perl dependency.

Alexandru Croitor (2 April 2019 18:12) replied:
> Unfortunately I have minimal knowledge of Perl. But adding tools
> one-by-one in different languages doesn't seem to me the right
> solution either (from a maintenance perspective).

If we get too many different languages, that could be a problem, yes.
On the other hand, evolving is good and some tools are better for
particular jobs than others.  I'm more concerned about tools having no
documentation of how to use them or what they're for (which I have run
into repeatedly - aside from the util/ things with no docs, several have
no more doc than a usage message and at least two only have docs because
I added them after I'd worked out how to use them in order to do so).

It would probably be a good idea to have a "permitted list" of languages
in which dev-related tools can be included in our source tree; and I
think it's pretty sensible to include
* python - we even have a team working on Qt for it
* go - Coin is written in it

If anything I'd leave off perl (and start porting scripts away from it)
because there are too few developers in this community willing to touch
it with a ten foot pole - and scarcely any that actively like working
in it.  (FTR: I'd far sooner review or hack on a python script than a
perl script; but I end up being maintainer and reviewer for perl scripts
because I don't actually refuse and can make sense of perl.)

As for having "minimal knowledge of Perl", if it were a nice language to
work in I'd just encourage you to learn - but I'm not going to do that
to you, as I'd sooner port the existing infrastructure away from it.
One can write nice maintainable perl, but this isn't industry-standard
practice and I do not like maintaining what is,

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

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Alexandru Croitor]

Unfortunately I have minimal knowledge of Perl. But adding tools one-by-one in 
different languages doesn't seem to me the right solution either (from a 
maintenance perspective).

> On 2. Apr 2019, at 17:43, Edward Welbourne  wrote:
> 
> Alexandru Croitor (2 April 2019 14:02)
>> Just to throw some wood into the fire, because it's that kind of day,
>> technically we don't require Python or Go to build qtbase, yet we
>> require Perl. Hence +1 for using the perl script, because we need Perl
>> anyway : P
> 
> That sounds a lot like you just volunteered to maintain and review perl
> scripts.  As one of those currently stuck doing so (mainly because
> few others will touch perl with a ten foot pole) I'd gladly replace all
> our perl infrastructure with python and replace the perl dependency.
> 
>   Eddy.

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

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Edward Welbourne]

Alexandru Croitor (2 April 2019 14:02)
> Just to throw some wood into the fire, because it's that kind of day,
> technically we don't require Python or Go to build qtbase, yet we
> require Perl. Hence +1 for using the perl script, because we need Perl
> anyway : P

That sounds a lot like you just volunteered to maintain and review perl
scripts.  As one of those currently stuck doing so (mainly because
few others will touch perl with a ten foot pole) I'd gladly replace all
our perl infrastructure with python and replace the perl dependency.

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

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Michael Winkelmann]

As we all know, Perl is a write-only language... SCNR

On 02.04.19 13:46, Cristián Maureira-Fredes wrote:
> 
> PS: Maybe some kind soul that speaks "Perl" can improve the current
> script?

-- 
---
Michael Winkelmann
Qt Advisor

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
michael.winkelm...@qt.io
+4915122973404
http://qt.io

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

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Tuesday, 2 April 2019 1:46 PM
> To: development@qt-project.org
> Subject: Re: [Development] Switching from create_changelog.pl to
> createchangelog for change log generation
> 
> 
> > On 2 Apr 2019, at 11:40, Mitch Curtis  wrote:
> > ...
> > So, the end result of switching to this is that it becomes clearer that we 
> > are
> actually fixing (non-trivial) bugs, contrary to what the "only minor code
> improvements" message says. Yes, it does mean that you will have to edit
> more stuff, but it's mostly just removing commit message bodies, which are
> included (if I understand correctly) in order to give more context than would
> otherwise be available had it just included the commit summary.
> >
> > If no one has any serious objections, I'd like for us to start using this to
> create the draft change file commits as soon as possible.
> >
> > [1]
> > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_ch
> > angelog.pl [2]
> > https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> >  dev.txt>___
> > 
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> Yeah thanks to Simon for starting that and for writing it in go.  ;-)
> 
> I added that feature to get all the bugs as well as the changelog entries: if 
> a
> Fixes or Task-number is found, it queries Jira for the bug subject line, and
> also includes the descriptive part of the commit message.  The result is
> verbose, but I prefer condensing it down rather than having to open up bugs
> individually in a browser whenever the commit message doesn’t tell the
> whole story.  Of course I also remove non-user-facing entries like doc fixes,
> fixes to really short-term regressions that didn’t get into a release, deep
> internal stuff etc.  And I have to reorganize them because the tool doesn’t
> detect which fixes are to QtQuick and which are to QtQML for example (let
> alone any finer-grained categories), although it could maybe be enhanced by
> looking at which files got changed.

Thanks!

> I found one more issue though when I was re-generating the 5.9.8
> changelog: it got confused that there were tags on newer branches.  I had to
> delete all the 5.12.x, 5.11.x and 5.10.x tags from my local checkout so that 
> it
> would see that 5.9.8 is the newest.  But I’m sure that can be fixed.
> 
> After that, we could indeed try using it for the mass changelog generation, as
> long as the other maintainers are OK with the verbosity that it generates.

Hmm, OK, so it's not quite ready to be used yet.

> ___
> 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] Switching from create_changelog.pl to createchangelog for change log generation

[Alexandru Croitor]

Just to throw some wood into the fire, because it's that kind of day, 
technically we don't require Python or Go to build qtbase, yet we require Perl. 
Hence +1 for using the perl script, because we need Perl anyway : P

On 2. Apr 2019, at 13:46, Cristián Maureira-Fredes 
mailto:cristian.maureira-fre...@qt.io>> wrote:

Hello Mitch,

On 4/2/19 11:40 AM, Mitch Curtis wrote:
Currently change files are generated using create_changelog.pl from qtsdk.git 
[1]. This works OK, but misses a lot of bug fixes. For example, the 5.12.3 
release of Qt Quick Controls 2 has a bunch of fixes, but create_changelog.pl 
still results in the "This release contains only minor code improvements" 
message:

https://codereview.qt-project.org/#/c/257810/1//ALL

Totally agree, that perl tool needs a bit of love, and it doesn't fit
all the needs from the different project we have in Qt.

Simon wrote createchangelog [2], which includes any changes with a Jira task 
number. To quote what the tool does:

commit 66f33fecc3b4a2896a4f33a3a7f06fb5cdd36dc8
Author: Simon Hausmann 
mailto:simon.hausm...@theqtcompany.com>>
Date:   Thu Feb 25 16:54:02 2016 +0100

Added little helper tool to create an initial changelog template for a 
module

Simply run the binary in the module directory with the correct branch 
checked
out.  The tool will peek at .qmake.conf to figure out the current version 
and
run git tag -l to see what the previous version is.

The resulting change log requires manual editing, but it is a start.

Change-Id: I975c0d7a74fee8cab2ae6f400972c5dbc73ff367
Reviewed-by: Robin Burchell 
mailto:robin.burch...@viroteck.net>>

I found that we had two tools to achieve the same
a couple of weeks ago, and I again agree that it's better than the perl
option.


And the README:

This little tool faciliates the creation of change log files for Qt 
modules. It is written in golang and
can be built by running

go build

With the binary in place, you can use it like this:

1. Change into a directory that contains a git clone of the module 
you'd like to create a change log for.
2. Make sure you have the release branch checked out that you'd like to 
create the file for.
3. Run the createchangelog tool from there.
4. The tool will parse .qmake.conf to determine the version of the 
upcoming release and it will use "git tag -l" to
   determine the previous release, in order to look through the git 
commits between the previous release and HEAD.
5. The proposed template output of the new change log file is printed 
to standard output, from which you can redirect
   it to a file and edit it accordingly.

To show examples of what the tool generates, I've attached its output when run 
on the 5.12.3 and dev branches of qtquickcontrols2.git.

So, the end result of switching to this is that it becomes clearer that we are 
actually fixing (non-trivial) bugs, contrary to what the "only minor code 
improvements" message says. Yes, it does mean that you will have to edit more 
stuff, but it's mostly just removing commit message bodies, which are included 
(if I understand correctly) in order to give more context than would otherwise 
be available had it just included the commit summary.

If no one has any serious objections, I'd like for us to start using this to 
create the draft change file commits as soon as possible.

Here is where I have a couple of issues.

Even though the code is not so complicated or long,
the build process is just a couple of seconds,
but having to build it on the first place is kind of "meh".

It's true that I can just build it once, and then forget about
it and just continue using it, but I'm under the impression the tool
also could evolve a bit more.

Moving around the script to generate changelogs is also something
that needs to be improve, since a command line option is the natural
solution.

The project parses the .qmake.conf so any project that doesn't have one
will be unable to use it, e.g.: PySide.

I know it's a feature of Go, but this also assumes that
the repositories:
go: finding github.com/eidolon/wordwrap 
v0.0.0-20161011182207-
go: finding 
github.com/hashicorp/go-version v1.1.0
go: finding 
github.com/andygrunwald/go-jira v1.6.0
go: finding 
github.com/trivago/tgo/tcontainer 
latest
go: finding 
github.com/google/go-querystring/query
 latest
go: finding github.com/fatih/structs v1.1.0
go: finding github.com/pkg/errors v0.8.1
go: finding 
github.com/google/go-querystring v1.0.0
go: finding github.com/trivago/tgo v1.0.6

will not change their names, or that the users will not remove

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Cristián Maureira-Fredes]

Hello Mitch,

On 4/2/19 11:40 AM, Mitch Curtis wrote:
> Currently change files are generated using create_changelog.pl from qtsdk.git 
> [1]. This works OK, but misses a lot of bug fixes. For example, the 5.12.3 
> release of Qt Quick Controls 2 has a bunch of fixes, but create_changelog.pl 
> still results in the "This release contains only minor code improvements" 
> message:
> 
> https://codereview.qt-project.org/#/c/257810/1//ALL

Totally agree, that perl tool needs a bit of love, and it doesn't fit
all the needs from the different project we have in Qt.

> Simon wrote createchangelog [2], which includes any changes with a Jira task 
> number. To quote what the tool does:
> 
> commit 66f33fecc3b4a2896a4f33a3a7f06fb5cdd36dc8
> Author: Simon Hausmann 
> Date:   Thu Feb 25 16:54:02 2016 +0100
> 
>  Added little helper tool to create an initial changelog template for a 
> module
>  
>  Simply run the binary in the module directory with the correct branch 
> checked
>  out.  The tool will peek at .qmake.conf to figure out the current 
> version and
>  run git tag -l to see what the previous version is.
>  
>  The resulting change log requires manual editing, but it is a start.
>  
>  Change-Id: I975c0d7a74fee8cab2ae6f400972c5dbc73ff367
>  Reviewed-by: Robin Burchell 

I found that we had two tools to achieve the same
a couple of weeks ago, and I again agree that it's better than the perl
option.

> 
> And the README:
> 
>  This little tool faciliates the creation of change log files for Qt 
> modules. It is written in golang and
>  can be built by running
> 
>  go build
> 
>  With the binary in place, you can use it like this:
> 
>  1. Change into a directory that contains a git clone of the module 
> you'd like to create a change log for.
>  2. Make sure you have the release branch checked out that you'd like 
> to create the file for.
>  3. Run the createchangelog tool from there.
>  4. The tool will parse .qmake.conf to determine the version of the 
> upcoming release and it will use "git tag -l" to
> determine the previous release, in order to look through the git 
> commits between the previous release and HEAD.
>  5. The proposed template output of the new change log file is 
> printed to standard output, from which you can redirect
> it to a file and edit it accordingly.
> 
> To show examples of what the tool generates, I've attached its output when 
> run on the 5.12.3 and dev branches of qtquickcontrols2.git.
> 
> So, the end result of switching to this is that it becomes clearer that we 
> are actually fixing (non-trivial) bugs, contrary to what the "only minor code 
> improvements" message says. Yes, it does mean that you will have to edit more 
> stuff, but it's mostly just removing commit message bodies, which are 
> included (if I understand correctly) in order to give more context than would 
> otherwise be available had it just included the commit summary.
> 
> If no one has any serious objections, I'd like for us to start using this to 
> create the draft change file commits as soon as possible.

Here is where I have a couple of issues.

Even though the code is not so complicated or long,
the build process is just a couple of seconds,
but having to build it on the first place is kind of "meh".

It's true that I can just build it once, and then forget about
it and just continue using it, but I'm under the impression the tool
also could evolve a bit more.

Moving around the script to generate changelogs is also something
that needs to be improve, since a command line option is the natural 
solution.

The project parses the .qmake.conf so any project that doesn't have one
will be unable to use it, e.g.: PySide.

I know it's a feature of Go, but this also assumes that
the repositories:
go: finding github.com/eidolon/wordwrap v0.0.0-20161011182207-
go: finding github.com/hashicorp/go-version v1.1.0
go: finding github.com/andygrunwald/go-jira v1.6.0
go: finding github.com/trivago/tgo/tcontainer latest
go: finding github.com/google/go-querystring/query latest
go: finding github.com/fatih/structs v1.1.0
go: finding github.com/pkg/errors v0.8.1
go: finding github.com/google/go-querystring v1.0.0
go: finding github.com/trivago/tgo v1.0.6

will not change their names, or that the users will not remove
their accounts, otherwise we will need to find our workarounds
by not using those modules.

Maybe someone with more "Go knowledge" than my limited
"hello world"-level can see if we can rely purely on the go
standard library?


Since I mentioned that I faced the problem of looking for a
"create change logs" tool, I wrote a simple /kind-of/ equivalent
script in Python to use it on the PySide project:
https://codereview.qt-project.org/#/c/252162/

At the moment does not have the option to specify another repository
because it was an ad-hoc solution for the PySide project,
but my point 

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Shawn Rutledge]

> On 2 Apr 2019, at 11:40, Mitch Curtis  wrote:
> ...
> So, the end result of switching to this is that it becomes clearer that we 
> are actually fixing (non-trivial) bugs, contrary to what the "only minor code 
> improvements" message says. Yes, it does mean that you will have to edit more 
> stuff, but it's mostly just removing commit message bodies, which are 
> included (if I understand correctly) in order to give more context than would 
> otherwise be available had it just included the commit summary.
> 
> If no one has any serious objections, I'd like for us to start using this to 
> create the draft change file commits as soon as possible. 
> 
> [1] 
> https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_changelog.pl
> [2] https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

Yeah thanks to Simon for starting that and for writing it in go.  ;-)

I added that feature to get all the bugs as well as the changelog entries: if a 
Fixes or Task-number is found, it queries Jira for the bug subject line, and 
also includes the descriptive part of the commit message.  The result is 
verbose, but I prefer condensing it down rather than having to open up bugs 
individually in a browser whenever the commit message doesn’t tell the whole 
story.  Of course I also remove non-user-facing entries like doc fixes, fixes 
to really short-term regressions that didn’t get into a release, deep internal 
stuff etc.  And I have to reorganize them because the tool doesn’t detect which 
fixes are to QtQuick and which are to QtQML for example (let alone any 
finer-grained categories), although it could maybe be enhanced by looking at 
which files got changed.

I found one more issue though when I was re-generating the 5.9.8 changelog: it 
got confused that there were tags on newer branches.  I had to delete all the 
5.12.x, 5.11.x and 5.10.x tags from my local checkout so that it would see that 
5.9.8 is the newest.  But I’m sure that can be fixed.

After that, we could indeed try using it for the mass changelog generation, as 
long as the other maintainers are OK with the verbosity that it generates.

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

[Development] Switching from create_changelog.pl to createchangelog for change log generation

[Mitch Curtis]

Currently change files are generated using create_changelog.pl from qtsdk.git 
[1]. This works OK, but misses a lot of bug fixes. For example, the 5.12.3 
release of Qt Quick Controls 2 has a bunch of fixes, but create_changelog.pl 
still results in the "This release contains only minor code improvements" 
message:

https://codereview.qt-project.org/#/c/257810/1//ALL

Simon wrote createchangelog [2], which includes any changes with a Jira task 
number. To quote what the tool does:

commit 66f33fecc3b4a2896a4f33a3a7f06fb5cdd36dc8
Author: Simon Hausmann 
Date:   Thu Feb 25 16:54:02 2016 +0100

Added little helper tool to create an initial changelog template for a 
module

Simply run the binary in the module directory with the correct branch 
checked
out.  The tool will peek at .qmake.conf to figure out the current version 
and
run git tag -l to see what the previous version is.

The resulting change log requires manual editing, but it is a start.

Change-Id: I975c0d7a74fee8cab2ae6f400972c5dbc73ff367
Reviewed-by: Robin Burchell 

And the README:

This little tool faciliates the creation of change log files for Qt 
modules. It is written in golang and
can be built by running

go build

With the binary in place, you can use it like this:

1. Change into a directory that contains a git clone of the module 
you'd like to create a change log for.
2. Make sure you have the release branch checked out that you'd like to 
create the file for.
3. Run the createchangelog tool from there.
4. The tool will parse .qmake.conf to determine the version of the 
upcoming release and it will use "git tag -l" to
   determine the previous release, in order to look through the git 
commits between the previous release and HEAD.
5. The proposed template output of the new change log file is printed 
to standard output, from which you can redirect
   it to a file and edit it accordingly.

To show examples of what the tool generates, I've attached its output when run 
on the 5.12.3 and dev branches of qtquickcontrols2.git.

So, the end result of switching to this is that it becomes clearer that we are 
actually fixing (non-trivial) bugs, contrary to what the "only minor code 
improvements" message says. Yes, it does mean that you will have to edit more 
stuff, but it's mostly just removing commit message bodies, which are included 
(if I understand correctly) in order to give more context than would otherwise 
be available had it just included the commit summary.

If no one has any serious objections, I'd like for us to start using this to 
create the draft change file commits as soon as possible. 

[1] 
https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_changelog.pl
[2] https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
Qt 5.12.3 is a bug-fix release. It maintains both forward and backward
compatibility (source and binary) with Qt 5.12.2.

For more details, refer to the online documentation included in this
distribution. The documentation is also available online:

  http://qt-project.org/doc/qt-5.12

The Qt version 5.12 series is binary compatible with the 5.11.x series.
Applications compiled for 5.11 will continue to run with 5.12.

Some of the changes listed in this file include issue tracking numbers
corresponding to tasks in the Qt Bug Tracker:

  http://bugreports.qt-project.org/

Each of these identifiers can be entered in the bug tracker to obtain more
information about a particular change.


*   Important Behavior Changes *



*  Library *


 - [QTBUG-70597] Attempt to stabilize Tumbler::test_itemsCorrectlyPositioned
   I'm not sure if this will help (because I haven't been able to
   reproduce the flakiness, even in a CI VM), but the tumbler should
   really not still be spinning after we got the position of its items,
   so make sure it's stopped before doing any comparisons.
 - [QTBUG-72786] Default: fix highlighted ItemDelegate colors
   - Make ItemDelegate respect highlightedText - Change ItemDelegate's
   highlightedText palette role from white to almost black (i.e inversion
   of "light" which is 0xFF090909), so that text shows up against a
   highlighted background. This also allows easily switching ComboBox to
   a dark style via palette customization.
 - [QTBUG-74512] Mark BaseValidator::throwRecursionDepthError() as final
 - [QTBUG-70451] DialogButtonBox: don't sort buttons based on their memory 
addresses
   When two buttons' roles are equal, the code would fall back