> On 18 Jun 2021, at 17:47, Martin Sebor via Gcc <gcc@gcc.gnu.org> wrote:
>
> On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote:
>> 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.
>
> Just to prevent a deadlock: Tobias, please feel free to reuse any
> parts of my patch if you wish, or just go with what you have if you
> prefer. I can submit whatever's left after you're done.
Hopefully, these improvements can still be used with ‘ git commit-mklog … ‘ so
that
there’s some what to separate out e.g. ‘-s’ (to the commit) from any arguments
used
for the mklog.
I’m totally in favour of automating this kind of thing (our current system is a
huge
improvement over what we had) - but we need to cater for a variety of
work-flows.
