I’ve been working in the GNOME community for a little under a year and a half now. During my time contributing to the project, I’ve seen a lot of misunderstandings from the community about how we work. So, I’ve decided to write a multi-part series on how development on GNOME works.
This first post will cover the basics. In future I’ll explain our tooling, how apps are created, and how changes happen across the ecosystem.
The Release Cycle
At the center of GNOME development is the release cycle. Every 6 months we put out a major release, with patch releases in-between. Major releases typically happen in September and March, and are named after the city of the most recent conference. GNOME 3.30 was named after the city we held GUADEC in, and 3.32 is named after where GNOME.Asia took place.
At different intervals in the cycle we have freeze periods, after which no changes can be made to certain parts of the code. Core apps, such as Web, Files, and Settings all strictly follow the release cycle and freezes. Apps outside of the core set like Polari, Builder, and Fractal can follow their own schedules or versioning schemes, but tend to put out releases alongside the GNOME core.
The freeze deadlines often determine what contributions make it into a release. For example, if a UI change is submitted after the UI freeze, maintainers need to seek approval from the Design and Release teams before the change can be merged. Freezes are staggered, and come in the following order:
- UI, Feature, and API/ABI Freezes
- String Freeze
- Hard Code Freeze
The hard code freeze ends once the major release for the cycle is out. If you want to apply a change that violates the other freezes, you need to create a branch for the latest stable release. So, if I need to merge a UI change after the 3.32 release is out, I need to first create a gnome-3-32 branch before I accept the change onto master. This branch will then be used to cherry-pick changes for the 3.32.X releases.
How Apps Are Maintained
Each project within GNOME has its own developers. The Music developers aren’t necessarily the same people working on the Shell, and the Shell developers generally aren’t the same people working on GTK. While many developers work across the ecosystem on different projects, there is no one team of developers. This is why “GNOME decided such and such” is often inaccurate.
The maintainers of a project have full say over what contributions are or are not accepted. While certain things can be proposed, maintainers have the right to reject proposals. This is, for example, is why Terminal did not have a HeaderBar until 3.32 and doesn’t enable it by default. Nobody is forced to do anything, but often developers and designers will agree on a direction for an app, or the ecosystem at large.
Contrary to popular belief, most maintainers are not paid by Red Hat although some core components like Files and GNOME Shell do have Red Hat employees employed to work on them. Other companies such as Canonical, Purism, and Endless employ developers to work on the parts of the stack that matter to them. That said, most contributors are not on company time even if they are employed by the likes of Red Hat. And of course those that are employed to work on GNOME still aren’t paid for all of their work on GNOME. Most of our work is done on our own time, as limited by the rest of our lives.
It’s also worth noting that GNOME is built with a wide range of technologies; while GTK is written exclusively in C, Music is a Python project and Calculator is implemented with Vala. The Python developers working on Music are great with Python and GStreamer, but they aren’t going to be much help fixing a rounding error in Calculator as a general rule, and as volunteers it wouldn’t be fair to expect them to be, either.
tl;dr: GNOME is a community of individuals each with their own motivations and vision for their own part of the project doing their best to build a great platform for users.
Polari and Builder are part of the GNOME’s core, and they follow the standard release cycle.
Fractal is out of the core, so it doesn’t need to follow it.
Polari and Builder are not core apps – core apps are the applications that are meant to be shipped in standard distributions
of GNOME. They have remained mostly unchanged since 3.26,
with the removal of Documents being the only change. Polari and Builder both are not in this set and thus have the freedom to choose their
releases.
Nice rundown of the process. I guess many people who are complaining see the GNOME foundation as the (benevolent or not) dictator that exists in so many FOSS projects. It sure does some governance, but as you correctly document, it’s the individual maintainers who decide on the direction of their app/library. While official guidelines such as HIG could be seen as confining maintainers to a certain direction, it’s not binding and you do can go a different direction. The app will just not end up in the core.
Though the guidelines are not set in stone and are developed in the open. I’ve read some comments here and there from GNOME 3 haters who will claim the opposite: that GNOME 3 design was an unexpected break with no input from outside. I remember it differently. It was around 2009/2010 and on the good old planet.gnome.org was quite some fuzz about the early work on a completely new GNOME experience in the form of gnome-shell, seeking to breathe new life into GNOME. I’m a casual GNOME user and was excited, even built an early prototype of the shell. If I had wanted to I could have jumped in contributing, but my priorities laid elsewhere.
Years have passed and GNOME changed a lot since 3.0. The basic design principles are still the same, a source of frustration for those who just not like it. While complaining is a thing, something better happened, they created their own desktop environments, like Budgie or Mate. Supporting all possible needs and wants drains resources, so it’s good that different projects exist that cater to the needs. It’s also good that Mate switched to GTK 3, so they do not have to maintain the old GTK 2.
Keep rolling!
A interesting, good, read. Looking forward to the next part of the series! And I hope there will be many following parts as this is the type of content I like.