Who doesn't like them? I updated the Haiku stats to keep track of
the activity in our git repository.
The overall number of commits is very similar to 2016 (which was our quietest
year so far) with more than 1300 commits (far from the 5555 commits in 2009).
Our author of the year is waddlesplash with 213 commitsi, followed by PulkoMandy,
Korli, Humdinger, Kallisti5, and Skipp_OSX. 65 different commiters
made changes to Haiku this year, a net increase from 48 in 2016, but not reaching
as high as 2012 (83 different committers). In the week-by-week graph you can
also clearly see the effect of the coding sprint, which is of course the week
with most commits.
It would be great if the colors for the new barber pole progress bar matched that of BeOS, meaning blue and white versus blue and blue. Other than that, it looks great
I found it fascinating to look at the stats and noticing that the code base has been hovering at around 550,000 lines of code since the end of 2015. It looks like there has been much clean-up in the code since the peak of around 1,200,000 lines of code in 2010. This is a very nimble code base especially when comparing it to that of the Linux Kernel which is trending at around 15,000,000 lines of code.
I noted the continued improvements to the USB 3.0 Stack and the UEFI interface. This is good as these components are now “standards” on systems currently on the market.
The drop in line of code count since 2010 is because we started using package management and could remove a lot of 3rd party code from our repo. Previously, most 3rd party libraries (ICU, ffmpeg, …) and tools (binutils, bash, …) were copied into our sources and their buildsystem rewritten to use Jam. Now these are built using haikuporter instead (and you can see the stats for that, too: http://pulkomandy.tk/stats_hp/ - with a big increase on activity this year)
So, Haikuport is where the roughly 700,000 lines of code which seemed to have disappear went!
Dividing up the code base in self-contained logical units makes sense. The short-term pains associated with the transition to package management now appear well worth the long-gains for the project.
It’d be worth nothing that lines of code on its own isn’t a terribly meaningful measure of things. A sizable chunk of the linux kernel consists of devices and filesystem drivers for various pieces of hardware (a lot of which we don’t support), which isn’t necessarily compiled in at all depending on the target architecture.
