I have been working for the MariaDB Foundation as the Chief Contributions Officer for a couple of weeks and it is fantastic being part of the MariaDB family again. Part of my job is to help the community massage pull requests into something that we can merge. I am, however, finding that one of the worst parts of my job is having to say “no” to contributions that clearly took a lot of time and effort on the part of the developer.
Contributions could be turned down or at least will require changes for a number of reasons. These include anticipated knock-on effects with the wider code-base, such as introducing new bugs or performance regressions elsewhere. The could also need revising due to pull requests against the wrong version, lack of tests, etc.
So, I figure I would write a rough guide that will help you get your code contributions in.
Step 1. Talk to us
The engineers behind MariaDB are very approachable, and I’m freely contactable by the community to act as a liaison between the community and the engineers as needed. If you have a really cool idea or found a bug you wish to work on, come talk to us. Communications via Jira or Zulip chat work well and we can advise on the general direction you should take or if there are any obstacles you maybe had not considered. We can also make sure it isn’t something that someone else happens to be working on.
Step 2. Code it up!
Work on hacking away at your patch. It is useful to us if you could track your progress in a Jira ticket, but that isn’t always required. If you get stuck or have any questions, you can again reach out to the engineers or contact me directly. Make sure you develop against the oldest supported release affected if this is a bug or the current development release if it is a feature. Information on how to do that is available here. You also need to make sure that any code confirms to our coding standards so that it is uniform across our code-base. The best way to do this right now is to look at the surrounding code and how that is formatted.
We really need test cases for whatever bug or feature you are working on. This is essential so that we can really see the true intention of the PR, make sure it is tested properly and to make sure an accidental regression doesn’t happen later. Further information on writing tests is available here.
Step 3. The pull request
When you open a pull request against MariaDB server you will get a template to fill. Filling this in helps us greatly triage the pull request and figure out its intention quickly. You will also need to sign the CLA or mention that you are providing the contribution under the 3-Clause BSD License (aka. the BSD-New License).
Step 4. The review
The MariaDB engineers will review the code and they will give advice as needed. When the engineers are happy with the pull request, the code will be approved and merged. Community members are also welcome to add their comments to pull requests. A contribution is more than code, it is also being part of the conversation.
I am personally trying to make sure we catch up with the pending code reviews. This will take a while but in the mean time if your review hasn’t been looked at in a little while you are welcome to tag me (@LinuxJedi on GitHub) in a comment and I can take a look.