News for hackers. Stuff that matters.

A comment on Finding a kernel regression in half an hour with git bisect run (2018). Parent comment

Re:Finding a kernel regression in half an hour with git bise... by btilly on Wednesday July 28, 2021 @06:38PM (#27990664)
The person who knows the change and thinks that it shouldn't have changed anything is probably in the best position to figure out why it broke something after all.

Probably refactoring according to a pattern, and missed something. Still, the person with context gets the bug.

[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by mandelbrotwurst on Wednesday July 28, 2021 @07:31PM (#27991065)
Eh, depends on what you’re optimizing for. For fixing the bug as quickly as possible, yes. For spreading that context throughout the team or getting other features out that the person with context is best equipped to ship, no.
[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by kawsper on Wednesday July 28, 2021 @08:01PM (#27991259)
If it is just reorganisation of project files then the fastest way to fix the bug would likely be to just revert the commits.
[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by alexeldeib on Wednesday July 28, 2021 @10:05PM (#27992013)
Consequently, this highlights why the first person may have an incentive to fix it: if their code gets reverted to fix the issue, they will definitionally be forced to rework it before they’re able to merge again.
[ Parent | on HN ]