This is the third and final part of a series I promised during my Nest With Fedora talk (also called “Exploring Our Bugs”). In this post, I’ll analyze the time it takes to resolve bug reports from Fedora Linux 19 to Fedora Linux 32. If you want to do your own analysis, the Jupyter notebook and source data are available on Pagure. These posts are not written to advocate any specific changes or policies. In fact, they may ask more questions than they answer.

An important consideration when looking at bugs is the time to resolution (TTR). How quickly are bugs resolved one way or another? The first thing I looked at is the TTR across all of our releases. As you might expect, it skews very heavily to the left. One surprising thing his how many bugs took multiple years to close. As a percentage, it was relatively small, but some bugs went almost 14 years before being closed. This is another time I wish it were easy to get a count of how many times a bug has been bumped to a later version.

One thing that occurs to me is that since F19 was the first release where we used an EOL closure status, it’s possible that it caught a disproportionate number of old bug reports. Looking at the mean and median TTR by release, F19 definitely had the highest values. I was glad to see that we’ve generally been trending toward faster resolution with each release. However, the oldest bug in each version has a more wavy pattern.

By category

If you recall in the previous post, I sorted the resolutions into a few categories. The table below gives a refresher. I thought it would be interesting to see the categories on their own.

Category	Resolutions
happy	CURRENTRELEASE, ERRATE, NEXTRELEASE, RAWHIDE, UPSTREAM
sad user	CANTFIX, DEFERRED, EOL, WONTFIX
sad maintainer	INSUFFICIENT_DATA, NOTABUG, WORKSFORME

Looking at just the happy resolutions, you can see that the TTR is decreasing. What’s more, the spread in TTR is also decreasing.

What about the sad user resolutions? Most people would prefer to know a bug won’t be fixed right away than to have it languish forever. The sad user resolutions are actually pretty steady over time. You can see a tight concentration at approximately one year. Since so many bugs are closed EOL, that makes sense. It might be reasonable to do this again with EOL bugs excluded.

What’s next?

I’ll start posting a summary after each EOL date so we can track our status. I’d like to figure out how we can improve our TTR and happy resolution rates without adding more burden to package maintainers. I’d love to hear your ideas. In the meantime, you can explore the data yourself, or look at my slides for more tables. If you have theories to explain anything you see in this post, let’s discuss those in the comments.