Interesting; when I work on a bug, then stopping at each finding and capturing it in a new comment on the bugzilla ticket helps me organize my thoughts. By writing it up as carefully as I can, as if I were guiding someone else through my argument, I distill and reinvestigate my thinking process.
Furthermore, the hunt can be so divergent and multi-branched that I can't keep everything in my mind. Attaching various debug patches and related logs that can be later referred back to is useful.
Also, frequent and relatively complete comments allows for controlled interruptions; it's easier to pick up the thread the next day when there's something comprehensive to re-read.
Here's one of my early, fond memories: https://bugzilla.redhat.com/show_bug.cgi?id=750283 -- that one took a week of work or so, IIRC.
I structure patch series, and write commit messages, the same way -- guiding the reviewer through my thought process. A few months or years later, I could be the "reviewer" myself again, for those same patches; it has happened.
I've checked out some debugging threads on Twitter (the website, retroactively). There's undeniably a drama / excitement element to the format, but it tends to lack context so badly that it's never convinced me.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: A feature, not a bug
Date: 2023-01-26 04:34 pm (UTC)Interesting; when I work on a bug, then stopping at each finding and capturing it in a new comment on the bugzilla ticket helps me organize my thoughts. By writing it up as carefully as I can, as if I were guiding someone else through my argument, I distill and reinvestigate my thinking process.
Furthermore, the hunt can be so divergent and multi-branched that I can't keep everything in my mind. Attaching various debug patches and related logs that can be later referred back to is useful.
Also, frequent and relatively complete comments allows for controlled interruptions; it's easier to pick up the thread the next day when there's something comprehensive to re-read.
Here's one of my early, fond memories: https://bugzilla.redhat.com/show_bug.cgi?id=750283 -- that one took a week of work or so, IIRC.
I structure patch series, and write commit messages, the same way -- guiding the reviewer through my thought process. A few months or years later, I could be the "reviewer" myself again, for those same patches; it has happened.
I've checked out some debugging threads on Twitter (the website, retroactively). There's undeniably a drama / excitement element to the format, but it tends to lack context so badly that it's never convinced me.
To each their own :)