Hacker News Reader

Comment by danuker | Hacker News Reader

Of 545 commits, 193 mention "fix" or "fixed" or "bug". That is 35.4%, quite high, compared to 10 large C projects I analyzed in 2019, which have a median of 25%.

That could mean file systems are hard to create, or that this particular one is buggy.

https://danuker.go.ro/frequency-of-bugfix-commits.html

Edit: looks like it's a problem with other file systems also:

https://github.com/pellepl/spiffs - 40.2%

https://github.com/tytso/e2fsprogs - 36.8%

But a reimplementation of exFAT is not as buggy: https://github.com/relan/exfat - 19.4%

View on HN

This seems like an awful metric. How many of those projects weren't placed on github until they'd stabilized a bit? Are they file systems? How big were the "bug fixes"? How disastrous/critical were the bug fixes? Do they have a unittest suite? What compilers and linters did they use?

Is it a problem, or is it that filesystems are not something you need to add new features to as often and thus commits are biased towards fixes? Or some other reason for a bias?

Or, maybe, it just indicates they prioritize fixing bugs over adding new buggy features.

In addition, the size of patches can also vary quite a lot on what the author considers a "thing". Some developers fix multiple things at once, while some others think every nut and bolt should be it's own separate commit

Yes I believe in save early save often and don't bother squashing and have multiple commits usually in my branch before a merge request. We have another team member that religiously squashes everything down to a single commit on his feature branch before requesting a pull from his branch. We don't have micromanagers so that's just the way things are.

But a reimplementation of exFAT is not as buggy

That's not surprising, because the FAT family is relatively simple for a filesystem. As a result, you can easily get read-only support done almost right the first time, and writing is only slightly more difficult.

Reply on news.ycombinator.com