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.
