3 ms·
What are they bisecting with? FreeBSD uses CVS and Perforce. These items in the slide don't add up: > Things had worked accidentally for years, due to linkers
by kazinator 2y ago
What are they bisecting with? FreeBSD uses CVS and Perforce.
These items in the slide don't add up:
> Things had worked accidentally for years, due to linkerset alphabetical ordering
In other words, the real bug is many years old. Yet, on the last slide:
> Since we found the bug within a week or so of it hitting the tree, the developer responsible was incredibly responsive. All the details were fresh in his memory.
What? Wasn't what hit the tree the ordering change which exposed the bug? It doesn't seem like that being fresh in anyone's mind is of much help.
- sakjur 2y agoFreeBSD has moved to Git as its primary VCS, see https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077858.html https://lists.freebsd.org/pipermail/freebsd-current/2020-Dec...
- drewg123 2y agoFreeBSD hasn't use CVS and P4 in decades. FreeBSD uses git internally, and has a github mirror. See https://docs.freebsd.org/en/articles/committers-guide/ https://docs.freebsd.org/en/articles/committers-guide/ The unintentional ordering change being fresh Colin's memory was really helpful, as he quickly realized that he'd actually changed the ordering and sent me a patch to fix it. If it had been 3 years in the past, I suspect he would have been less responsive (I know I would have been).
- pronoiac 2y agoThere were two sets of bugs: * the new sort handled ties differently. They adjusted that, and they could have stopped there. * the other was that the correct drivers were sensitive to loading order. They handled this and another driver bug, amdtemp. This was masked by the old sort. If they'd found this years later, even investigating the first set would be a slower process - it wouldn't be fresh in minds, and it likely would then have other code relying on it, so adjusting it would be trickier.