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

[Shawn Rutledge]

> On 2 Apr 2019, at 11:40, Mitch Curtis <mitch.curtis at qt.io> 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
> <qtquickcontrols2-5.12.3.txt><qtquickcontrols2-dev.txt>_______________________________________________
> Development mailing list
> Development at 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.