Last May we were invited to deliver a talk at Akademy-es, about the development history of KDevelop. Unfortunately, we had some issues downloading information from their Bugzilla (basically, we were hammering it, asking for all changes to all tickets, and it seems we were banned access). After some tinkering with delays and with different ways of getting information out of Bugzilla, we finally could get the complete status of all the tickets up to June 17th (7,255 tickets). And after some hectic weeks starting up the company, finally we had some time to complete the analysis on those tickets.
With this new information, we’ve updated the slides we used for the talk. It now includes the analysis of the git repository, which deals with more than 12 years of history (from January 1999 to April 2012), and the complete analysis of Bugzilla tickets, for a simialar period. The slides includes some interesting plots on the evolution of the source code of the project, on different kinds of activity (commits, ticket handling, etc.), among which we show here a couple of them.
The next graph shows nicely when the project had more activity in the past (or when it was shaken up for some reason), and is a good complement to the plot showing the number of commits per month.
And it shows a rather complementary view to the next one, which presents how the project evolved in code size over time. Both, combined, show moments of refactoring, of moving code to other projects, of adding new loads of code. Both also help to understand when the project is growing, when it is more like in maintenance mode, etc.
This next one is also quite informative, and tells a lot about the performance of the project.
Most of the tickets are closed in days. And in fact, when you look at the evolution of the quantiles (how long does it take to close a certain percentage of tickets ), this is more clear. In the next plot, it is shown how starting in 2002 (which is the point from when the data is more reliable, because a couple of years of tickets are incomplete in the project’s Bugzilla), time to close the quickest-closed 25% of tickets is very close to 0, and in general, time-to-fix is getting shorter and shorter over time.
But how close? This lineal graph makes it difficult to appreciate what is happening in the vicinity of 0. So,let’s look at the logaritmic one (below).
Here it is more clear how the time to close the quickest-fixed 25% of the tickets is around 100 minutes for several years, under 1000 minutes (16 hours) since 2006, and in any case most of the time well below 10000 minutes (7 days). But even for the 50%, 95% and 99% quantiles, times are quite reasonable, and getting down.
In summary, this presentation tried to show which kind of things we can uncover when throwing the appropriate tools at the data in the source code management and issue tracking repositories of a free software project, while at the same time trying to tell something useful to KDevelop developers, and to people interested in the project. Any feedback about whether you found this interesting or not would be more than welcome.
Leave a Reply