Alright everyone, good morning.
So my name is Andrew Hutchings, I'm also known as Linux Jedi everywhere, long story
behind that, another time.
I'm the Chief Contributions Officer for MariaDB Foundation and I want to start out by kind
of saying what all the different MariaDBs are because when someone uses the term MariaDB
it can mean a lot of different things.
So there's MariaDB Server which is the software kind of everyone knows, there's MariaDB Corporation
which is the kind of for-profit entity that does all the support, consulting, they do
SkySQL, Max Scale, etc.
Then there's the Foundation which is a non-profit entity, we're funded by kind of lots of different
third party companies and we are there to essentially continue the MariaDB source code
for the community essentially.
So bit of a weird job title, Chief Contributions Officer.
So I'm going to explain it using the pillars of the MariaDB Foundation and how they apply
to my roles.
So this and the MariaDB Foundation are openness, adoption and continuity.
And on the continuity side I try and make all the kinds of different contributions easier
for the community to contribute by reducing the kind of time between opening and closing
pull requests but not on the cost of quality or communications to the contributor.
On the openness side we create and publish metrics, I'll be talking about those a little
bit but essentially it's so you can see exactly what is going on with the community contributions.
And on the adoption side we work with communities such as operating systems and also end applications
such as WordPress that use MariaDB to make sure that we can integrate well with them
and grow adoption that way.
So there are lots of different types of contributions, when people hear the word contribution they
usually think of code contributions and those are the ones I'm mostly going to be talking
about today.
But there are lots of others that are important, you know funding for a non-profit kind of
foundation is really important, it helps us kind of grow the community around everything.
Documentation is really important, if you can't contribute code then contributing documentation
is quite useful for us.
See I say this because we have a Zulip, we have people asking questions on Stack Overflow,
Reddit, we have a community Slack, we have mailing lists etc. and the small foundation
can't get to everyone and everywhere so you know if you know how to answer a question
then you know it's a contribution to kind of reply and would love you for it.
And so I grew up in England, we suck at languages, I barely speak English, it's terrible.
So any help we can get with translating error messages, things like that is really useful
to us and we're working on making that a bit easier on a workflow point of view.
And then usage, bug reports, feature requests, actually using the thing and telling us what
you like, you don't like, what's broken, what's not broken, what you want in there.
That's a contribution and that's really useful to us as well, just as much as a code contribution
is.
So going a bit further into non-code contributions, I'm going to talk a little bit about Intel
who's a sponsor of ours.
They do lots of non-code contributions, sorry morning, and they can't really do that many
code contributions due to some legal stuff that they have to go through every time they
contribute code.
But they are doing things like they're constantly benchmarking MariaDB against their current
and upcoming hardware and feeding back the information to us of what's working, what's
not working, what hardware combinations are working, what's not working.
And when they do spot some kind of regression on some new hardware or something like that
or there's a release that's caused a regression on their hardware, they will dig deep and
tell us where to look in the code, what they've spotted and then our engineers can then work
on improving that.
So they've worked a lot with Marco in ADB, I'm sure he's in here somewhere, to improve
the performance certainly in 10.6 recently.
They do supply us with hardware to test against, so a lot of the billboard infrastructures
on Intel hardware, they've given us financial support.
And Steve Shaw from Intel is on the board for the MariaDB Foundation.
So there will always be things you can do to contribute even if you can't contribute
code to MariaDB.
Why contribution is important?
Well, so we get a more diverse input from each life experience.
So if a project is built by one team in one country, in one office, for example, you're
not going to get a diverse feel of not just culture, but use cases, et cetera.
So I think it's really important to get contributions for a wide group of people.
You get to direct a project the way the users want rather than being led by one single entity,
one single corporation.
So if a corporation says, OK, all the money is here, they're going to put all the resources
to develop those features and it might not be what somebody using WordPress wants, for
example.
You're fixing bugs and things that are important to you, and I think that's quite important.
And you're building a real community around the project.
So it wouldn't be a fuss to me if I don't talk about Drizzle.
For those who don't know, Drizzle was a database server, it was a fork in MySQL 6 back in 2009.
It started in some micro systems and it was designed to be a micro kernel kind of fork
with loads of different plugins optimized for web and cloud usage.
It eventually died, so that's why you probably haven't heard of it.
But in 2009, we had a talk where we said we want 50% of the code contributions to come
outside of some micro systems, and we kind of met this goal in a unique way.
Oracle bought some and fired everybody.
So we did meet the goal and everyone went to Rackspace, but my point is, MariaDB Server
has more external contributors than internal contributors.
So the corporation has, in 2022, 36 code contributors, there's eight from the MariaDB Foundation,
and there were 68 code contributors elsewhere.
Now, obviously, those contributors are not working full time on the code base, but it
does mean that they kind of fix the problems that are important to them.
And it's a pretty impressive stat, I think.
And we had similar stats in 2019, you know, kind of something happened in 2020, can't
think what, that kind of, of course it was kind of implied, but yes.
Also, many of the contributions we've got from China, and that was visited a lot before
the COVID.
Yeah.
So if you don't see contributors, they forget.
Exactly.
So as Monty said, COVID hit, China kind of caused the stats to dip a little bit, and
things like that.
They started to get back up again in 2021 and 2022 has probably been our best year ever,
and I think we got some really big stuff lined up for 2023 as well.
So the actual stats for 2022 are on screen right now.
So corporation, obviously, is the biggest contributor.
They pay a lot of full time developers to work on it.
We have a smaller number in the foundation of full time developers and some people who
work part time on the code and things like that as well.
So even I contribute a little bit, but now we're near as much as everyone else, you
know, at most one day a week, so it's not the huge amount.
And then other contributors kind of outside of the MariaDB circle, pretty much on par
with what the foundation contributes, so pretty good.
So we use Git DM, which is called Git Data Miner, to actually process the Git commit
stream to generate this.
And I've actually open sourced the tooling that does all this, and it has all the kind
of metadata in there to generate this.
So you can actually break it down by user, by entity they work for, et cetera.
And if you find that I've made a mistake on identifying someone, you can actually open
a pull request on that and change the data accordingly.
So it's kind of open in that respect as well, if you see what I mean.
Git Data Miner was something that was generated, it was created for the Linux kernel.
We tweaked it a little bit so we can count hackers and things like that, but yeah, it's
essentially the same tool.
We have a script to generate pull requests.
I know this chart is going to be difficult to see on the screen, but kind of the trend
is the important part.
So this scrapes GitHub for weekly pull request metrics.
So the X axis here is weak numbers, and then the Y axis is the number of open pull requests.
So the bottom is 80, the top is 120.
Part of my job is to help bring this down.
I have been failing.
I will be working on that quite a bit in 2023.
So I'd run.
You should also add how many actually close to that one, how many are open.
I do have that, but showing that on this chart was getting very messy.
So it's hard enough just showing this.
We do close a hell of a lot of pull requests as well, and we don't just go in and say,
no, that's rubbish close.
We tend to talk to people through the pull request, and that's why some of us stay open
quite a long time.
So in the metrics future, I kind of want to break down the commit contributions by module,
engine, et cetera.
So we know how many contributions are coming to InnoDB, how many to connect engine, how
many to ROXDB, et cetera, so that we can track that kind of usage.
I want to track the average time to merge pull requests, median and mean, I guess, probably
median because we've got some that have been open a couple of years and some that only
stay open a week or two, for example.
But we'll track that.
We'll bring it down.
Buildbot contribution metrics.
So we use buildbot for continuous integration.
We do get pull requests through that, contributions through that.
So we'd love to track that kind of stuff.
More community-wide metrics.
So we're talking Jira.
We're talking Stack Overflow Reddit metrics, et cetera, like that, capturing those kind
of things and publishing along with the quarterly stats that I already published on meridb.org.
And if there's any other metrics you want to see, let us know.
Contact us because we are happy to generate them.
So we'll talk about how to contribute code to Meridb.
I wrote a blog post about this on meridb.org, but there are some basic steps you can follow.
And it kind of helps reduce the round trip time during review.
And also, I don't want you to spend hours, days working on something and opening a pull
request and saying, sorry, this doesn't really fit with what we're doing at all or someone
else has already done this.
And I have to say no, because I don't want to crush people's hopes or anything like that.
So if you follow these steps, it will kind of help reduce that quite a bit.
So the first step is communication, talking to us.
We can guide you through kind of every step of the way.
Meridb team are quite approachable, preferably via Jira and Zulit, but there are other ways
to talk to us as well.
In particular, Vicente Daniel and me at the foundation, there are a list of people at
the corporation I'm sure you can talk to as well.
Tell us what you want to work on.
And if you don't know what you want to work on, there is a beginner-friendly tag on Jira
where we've tagged tickets that should be relatively easy to pick up and work on.
And we can talk you through these.
If there's no Jira for what you want to work on yet, open one and again, talk to us and
we can figure out the best solution for it.
Next step is hacking.
Write some codes.
If you are making a bug fix, it needs to be against the oldest-affected version of Meridb,
so if it affects 10.5 upwards, then against 10.5.
What is the thing that active release?
Yes, active release.
Yes, this is a good point.
Always check the end of life as well for the releases when you do this because we're in
this weird phase right now where we have got, we changed release cycles a couple of years
ago, so some releases are on the old release cycle and some are on the new release cycles
so some in the middle are end of life but some are.
So it's a bit funny right now, but again, you can talk to us about this and we can help
point in the right direction.
The new features always go in the latest development version, which currently is 11.0 for the next
couple of weeks.
When that hits GA, there'll be another release you can bolt things on.
Please stick to the coding standards to the surrounding code.
You'll find that different engines have different coding standards because they've come from
different places.
Connect engine was originally a MySQL contribution that came through to MarineDB and that's got
a different coding standard to say NODB and the core server code.
I've put together a coding standards document which should be merged shortly and that's
just for the core server and at the moment it's descriptive, run and prescriptive, but
we're going to improve on that over time.
Some test cases, we don't want you to write something, us merge it and then us break it
later.
So if you have some test cases in there, A, it proves exactly what you're doing and
B, it means that it will stay like that in the future.
Run the MTR test suite locally because otherwise you might get build bar errors that you don't
expect and it just reduces the cycle a little bit there.
If it's a new feature, help us write some documentation or at least describe what it
does in the JIRA tickets so that we can put that into the knowledge base at a later day.
Next up, pull requests.
When you open a pull request, a form will pop up and filling this in will help us triage
the pull request essentially.
So a lot of your questions about whether this is a bug or a feature, have you added a test,
does this break things, stuff like that.
If it's your first time doing a pull request, something called the CLA assistant will pop
up.
It's not 100% intuitive right now, it's something we need to improve on, but right now it will
pop up and ask you to sign the CLA.
You can click through that and either sign the CLA or tick to say, I want to contribute
under the three clause BSD license or you can just literally put a comment in and say,
I'm contributing this under the three clause BSD license and then we can take it from there.
What will run on the pull request automatically, lots and lots of different builders.
The most important ones will report back to GitHub and show you that if anything has failed
during compiling or testing on lots of different platforms we support.
When we actually go to review it, we'll actually look at the full build list where there might
be some obscure platforms that might have broken in weird ways, but at least it gives
you some idea of what's gone wrong and you can click through and look at the cause.
Again, if you don't understand the error that popped up, we can look at it for you and point
you in the right direction.
Code review process, the MariaDB engineers, both at the Foundation and Corporation will
review, give feedback, advice.
If we think the code is ready, we'll approve it and merge it.
Community members are also welcome to come look at the codes that people have contributed
to it, review it, comment on it, and it's another way you can contribute.
If we are taking time to get to your pull request and we're dropping the ball or something
like that or you need advice, you can tag me at Linus Jedi on GitHub and I will take
a look at it for you.
I'm lagging a bit behind on that because I'm at FOSDM right now, but I will try and
keep up with that.
We have a large backlog right now, so it is very easy for us to miss things.
That is all I have.
Any questions from anyone?
Yes.
Is the Foundation and the Corporation have different release cycles or is that?
It's Foundational Corporation different release cycles.
So no.
At the moment, the Corporation are generating the releases, so the engineers at the Corporation
are generating the releases, if you see what I mean.
The releases you get are generated by the Corporation.
Built by the Foundation, yes.
There's a lot of synergies between the two, which is a good thing.
We want to be working closely with them, if you see what I mean.
But if anything, God forbid, happened to the Corporation, the Foundation existing means
that MarineDB Server will still exist, will still be developed, et cetera.
All right.
Thank you very much.
Thank you.