www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12240] New: The changed.d tool should search git commits rather than query bugzilla

reply d-bugmail puremagic.com writes:
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: -------
Feb 24 2014
parent d-bugmail puremagic.com writes:
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: -------
Feb 25 2014