git gcc-commit-mklog doesn't extract PR number to ChangeLog

Richard Earnshaw Richard.Earnshaw@foss.arm.com
Fri Jun 18 09:32:33 GMT 2021


On 17/06/2021 18:21, Jakub Jelinek wrote:
> On Thu, Jun 17, 2021 at 05:12:52PM +0000, Joseph Myers wrote:
>> On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote:
>>
>>> It seems a bit dangerous to me to rely on just extracting PR numbers from
>>> tests.  What if the patch is just adjusting a test to make it compatible with
>>> the remainder of the change?
>>
>> Also, that a test is added for a PR, or a commit is relevant to a PR, is a 
>> weaker property than the commit *resolving* the PR.  The fact that a 
>> commit *resolves* a PR (allows it to be marked as resolved, or the 
>> regression markers to be updated if it's resolved in master but the fix 
>> still needs to be backported) needs to be explicitly affirmed by the 
>> committer (possibly based on a question asked by a script) rather than 
>> assumed by default based on the PR being mentioned somewhere.
> 
> 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.
> 
> 	Jakub
> 


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.

R.


More information about the Gcc mailing list