digitalmars.D.bugs - [Issue 12240] New: The changed.d tool should search git commits rather than query bugzilla
- d-bugmail puremagic.com (24/24) Feb 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12240
- d-bugmail puremagic.com (32/32) Feb 25 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12240
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 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
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 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