MariaDB Server GitHub branches: Moving to “main”

On the 3rd of July, two weeks ago, I created a poll to ask about the future of feature development branches in MariaDB Server. Specifically, whether we should switch to a rolling model which is more familiar to users of services such as GitHub.

The votes we received gave a very clear result. Today I will share the conclusions we drew, as well as setting expectations for what will happen next.

Recap: what is this “main” branch all about?

In a rolling model, there is one main branch of the tree that all the feature commits go into (typically called “main”), and this is then forked when it is time to prepare a major release.

This is in contrast to the current model used by MariaDB Server today, with which a new feature branch is created at some point during the cycle of the previous feature branch.

The Results: 76% want “main”

We had 33 in total voting, 8 for the current method, 25 for the proposed change. That is 76% in favour of changing to using a “main” branch.

Even if there were just 33 voters, the answer is clear enough to draw conclusions from. Thus, we can close the poll and share the outcome with you.

Without violating any privacy, I can share some insights about the voters, so you can paint yourself a picture about the validity of the results. When voting, an email address is required. This email address isn’t used or validated at the server side, but it does help deduplicate votes. One interesting dynamic is that of the 8 voting for the current method, at least half of them used anonymous or fake addresses, whereas everyone voting for the change provided a valid address. This allows us to see that votes came from all corners of the community, which is great to see.

What next? How will we move to “main”?

A 76% vote is clear enough. We can take a hint, we will move to ’main’! But this change won’t happen overnight. This is because the knock-on effects to processes and how it affects Buildbot configurations need to be planned out.

The changes need to be planned in detail, particularly in documentation. It reflects our code-level documentation in GitHub, it has implications for the Knowledge Base, and obviously, we need to agree on these details with the key developers. As the new process is figured out, we will communicate the detail changes.

Thank you

Thanks to everyone who voted and participated in conversations around this. With continued feedback, we will be able to improve things even further for the community.