The changed.d tool should search git commits rather than query bugzilla

[wilzbach]

Note: the issue was created automatically migrated from https://issues.dlang.org

Original bug ID: BZ#12240 From: Andrej Mitrovic <andrej.mitrovich@gmail.com> Reported version: D2 CC: dlang-bugzilla@thecybershadow.net, @wilzbach

[wilzbach]

Comment author: Andrej Mitrovic <andrej.mitrovich@gmail.com>

Currently the changelog generator tool ends up listing false-positives in the changelog because it is based on a date range when querying bugzilla tickets rather than actually checking what is in a release branch.

Another recent example of a false-positive:

E.g.: [22:38] Hmm, somebody reopened a bug that was fixed, and I closed it and reset it to its prior status once I confirmed the reopen was invalid, now it's in the changelog (Issue 1804)

[wilzbach]

Comment author: Vladimir Panteleev <dlang-bugzilla@thecybershadow.net>

More advantages:

• Using pull requests for changelog generation also frees us from the "paperwork" of filing an issue just for documenting a change.
• Using a date range no longer works with the new release process. A bug fixed in "master" but not the release branch will show up on the release's changelog (and respectively be omitted in the next release's changelog).

Plan:

• Generate the git log between the two tags. It is trivial to extract the pull request URLs from the git log. Digger 1 does this.
• Additional information can be obtained by querying GitHub using its API.

Questions:

• We still need a way to figure out whether a particular pull should be included in the changelog. For example:
  • Fixes to features added after the last release
  • Fixes to regressions introduced after the last release
  • Changes which do not affect D users, such as refactorings Although this can be done by hand at changelog generation time, that would be suboptimal and error-prone. One way to do this would be naming conventions for pull request topics, e.g. [internal]. (GitHub issue tags have the disadvantage that only repo collabs can assign them.)

[wilzbach]

Comment author: @wilzbach

This has apparently been fixed a while ago. It would still be nice to show the regarding PR that introduced a new feature, but AFAICT that's an issue for another day.