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).
With respect to total activity in the project, it is also shown how GNOME 3.0 meant a clear change in the landscape: commits, and ticketing activity more than doubled. After it, things have slowly come back to their origins, and now activity again similar to the pre-3.0 times.