3 ms·

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%

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 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 https://github.com/pellepl/spiffs - 40.2% https://github.com/tytso/e2fsprogs https://github.com/tytso/e2fsprogs - 36.8% But a reimplementation of exFAT is not as buggy: https://github.com/relan/exfat https://github.com/relan/exfat - 19.4%

userbinator 5y ago
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.
bonyt 5y ago
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?
Rexxar 5y ago
Or, maybe, it just indicates they prioritize fixing bugs over adding new buggy features.
- authorityofnil 5y ago
  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
  - stjohnswarts 5y ago
    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.
stjohnswarts 5y ago
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?

userbinator 5y ago

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.

bonyt 5y ago

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?

Rexxar 5y ago

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

authorityofnil 5y ago
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
- stjohnswarts 5y ago
  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.

stjohnswarts 5y ago

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?