Last year I
wrote about kernel commits that are tagged with the "Fixes" tag. Kernel developers use
the "Fixes" tag on a bug fix commit to reference an older commit that originally
introduced the bug. The adoption of the tag has been steadily increasing since v3.12 of the kernel:
The red line shows the number of commits per release of the kernel, and the blue line shows the number of commits that contain a "Fixes" tag.
In terms of % of commits that contain the "Fixes" tag, one can see it has been steadily increasing since v3.12 and almost 12.5% of kernel commits in v4.20 are tagged this way.
The fixes tag contains the commit SHA of the commit that was fixed, so one can look up the date of the fix and of the commit being fixed and determine the time taken to fix a bug.
As one can see, a lot of issues get fixed on the first few hundred days, and some bugs take years to get fixed. Zooming into the first hundred days of fixes the distribution looks like:
..the modal point is at day 4, I suspect these are issues that get found quickly when commits land in linux-next and are found in early testing, integration builds and static analysis.
Out of the thousands of "Fixes" tagged commits and the time to fix an issue one can determine how long it takes to fix a specific percentage of the bugs:
In the graph above, 50% of fixes are made within 151 days of the original commit, ~69% of fixes are made within a year of the original commit and ~82% of fixes are made within 2 years. The long tail indicates that there are some bugs that take a while to be found and fixed, the final 10% of bugs take more than 3.5 years to be found and fixed.
Comparing the time to fix issues for kernel versions v4.0, v4.10 and v4.20 for bugs that are fixed in less than 50 days we have:
... the trends are similar, however it is worth noting that more bugs are getting found and fixed a little faster in v4.10 and v4.20 than v4.0. It will be interesting to see how these trends develop over the next few years.
