https://d.puremagic.com/issues/show_bug.cgi?id=12240

           Summary: The changed.d tool should search git commits rather
                    than query bugzilla
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tools
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2014-02-24 13:43:10 PST ---
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)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=12240


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |thecybershadow@gmail.com
         AssignedTo|nobody@puremagic.com        |thecybershadow@gmail.com


--- Comment #1 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-02-25 18:10:39 EET ---
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

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------