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

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Shawn Rutledge
> Sent: Tuesday, 2 April 2019 1:46 PM
> To: development at 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 <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_ch
> > angelog.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.

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 at qt-project.org
> https://lists.qt-project.org/listinfo/development