GNOME was one of the first projects adopting time-based release management in 2002. So, in the last ten years GNOME has published a new release each March and September with only one exception: GNOME 3.0 and the introduction of GNOME Shell. Given this history, how has the time-based release plan affected GNOME projects? In our report on GNOME Shell we have analyzed and visualized GNOME Shell activity, and the results clearly show how GNOME projects are orchestrated.
[The image above is just a static preview, click on it to see the live interactive chart, and to learn about the meaning of each element in the figure]
The information displayed shows the activity (commits and tickets) of the project since 2009. A clear, large peak can be seen when GNOME 3 was released, but for each major release (labeled in the chart) clear increments of activity can also be shown. In fact, the graph shows how GNOME is working with a rhythm: every six months there is a rush to report, fix and commit, with periods of less activity in between. As expected, commit and ticketing cycles are not perfectly synchronized: commits happen mostly just before release-time (to have new functionality and fixes ready for the release); the increase in closing tickets happens before or around it (to have a release as bug-free as possible, and to fix the most urgent issues raised by the distribution of the release); and the increase in opening tickets comes mostly after it (as new bugs introduced by the release are reported).
Continue reading “The Rhythm of GNOME: GNOME Shell”