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

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] <Safety0ff> 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)

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.) [1]: https://github.com/CyberShadow/Digger

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.