Rant about unprofessional workflow

If you require every commit to reference an issue, then for trivial commits it might take a couple of minutes to copy a few lines from the commit message into the issue tracker which nobody will ever look at again, so it's wasted time. (For multiple closely-related commits you could combine them into a single issue, like "Fix coding style in xyzzy driver", so it's really an overhead per group of related work, not per commit.)

But if you don't require every commit to reference an issue (and enforce that requirement), someone will occasionally make an important substantive commit without an issue, which will turn out to introduce some bugs or need backporting or need some documentation written about its rationale etc, and someone will have to spend hours searching through mailing lists and LWN articles trying to find all the possibly-years-old discussions about that commit (earlier versions, code reviews, related bug reports, etc). That's also wasted time, which could have been saved if the discussion about the commit had been tracked in a single place (even just as a collection of links to mailing list threads).

If you require only substantive commits to reference an issue, you'll waste time deciding and then arguing with people over whether a commit is really substantive (e.g. a malloc/free bug could be a serious security vulnerability so surely that counts?), and you'll still sometimes fail to track a commit that should have been tracked.

I think it's unclear which approach wastes the most time overall, but the most predictable is to require an issue for every commit - it's a mildly irritating overhead when writing patches, but it's easy to get into the habit of using the issue tracker for everything, and it can save some rare but substantial headaches in the future.

Whitespace, typo fixes, merge errors - they don't warrant issue tracker entries. The malloc/delete mismatches could be real, user facing errors (e.g. destructor not called), these should be tracked.