On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus <tob...@codesourcery.com>
wrote:

> On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
> > On 17/06/2021 18:21, Jakub Jelinek wrote:
> >> mklog as is doesn't fill in the details (descriptions of the changes
> >> to each function etc.), nor is realiable in many cases, and with Jason's
> >> recent change just fills in the first and last part of the first line
> >> but not the important middle part.
> >> So, the developer has to hand edit it anyway and that I'd consider also
> >> be the right time when the verification whether the PR being mentioned
> >> is the right one etc.  So no need to add a question asked by the script
> >> at another point.
> > That misses my point.  If we use a tool to help doing this we can make
> > the tool also scrape the entry out of bugzilla and print the summary
> > line as a stronger visual check that the number has been typed
> > correctly.  We get many bug attributions wrong simply because two digits
> > have been transposed: visually checking the summary line is a far
> > stronger check that the correct number has been entered.
>
> I want to point out that 'mklog -p' already outputs the bug-summary lines
> at the top of the generated changelog, by fetching them from Bugzilla
>
> This patch extends this by:
> * Being able to specify the PR numbers on the command line in addition
>    (currently, they are only extracted from the testsuite patches)
>

This bit seems unnecessary to me, since we want the commit to include tests
that identify the PR.

Martin Sebor's patch to extract the PR number from the testcase filename,
as an alternative to a comment, should be enough.

Jason

Reply via email to