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 dekhn on Wednesday July 28, 2021 @07:15PM (#27990966)
i worked with code that could be broken by a wide range of things, anything from a change in tensorflow, XLA, device drivers, firmware, a support library, to cluster software upgrades that happens async (sometimes months after checkin) from changes in the repo.

I used to update a major numerical python library periodically, and sometimes the global test would show that some Java code broke. at first, I assumed it was just a false positive, but some sleuthing showed the Java code had embedded a python script that ran numpy to compute something over an array (whyyyyyyyyy) and numpy just happened to start outputting some slightly different values for that computation.

These are the perils and promises of the monorepo.

[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by mey on Wednesday July 28, 2021 @08:52PM (#27991549)
Out of curiosity, was there a process to raise that design "oddity" to someone? Is there a way in the Google mono-repo to even know who is responsible for which section?
[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by iamstupidsimple on Wednesday July 28, 2021 @08:54PM (#27991560)
There are 'OWNERS' files which list email addresses for directories, but anyone can contribute any piece of code. Generally, it is like a giant open source project to the eyes of a developer.
[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by dekhn on Thursday July 29, 2021 @09:00AM (#27995969)
yes you can use the 'blame' feature to identify specific lines, or look in piper to see who edited a directory recently. In addition to OWNERS files.

By the time I finished maintaining numpy, I could more or less find the right person with a couple minutes poking. Again, it's one of the things that google managed to do well- a large scale code base with many developers working more or less in concert, with efficiency at scale.

[ Parent | on HN ]
Re:Finding a kernel regression in half an hour with git bise... by joshuamorton on Thursday July 29, 2021 @04:28AM (#27994171)
You can still do the sneaky thing to query the build graph and only get changes in the transitive dependencies. This is almost always far smaller than the entire range between good and bad. For fast tests, the cost of doing the dependency lookup can be not worth it, but if your bisection will take more than 10 minutes, it's probably worth the effort.

It's still a little more complicated because then you have to bisect over a list of changes and not a raw range, but still.

[ Parent | on HN ]