[00:00.000 --> 00:17.680] Alright everyone, good morning. [00:17.680 --> 00:24.200] So my name is Andrew Hutchings, I'm also known as Linux Jedi everywhere, long story [00:24.200 --> 00:26.200] behind that, another time. [00:26.200 --> 00:31.400] I'm the Chief Contributions Officer for MariaDB Foundation and I want to start out by kind [00:31.400 --> 00:35.640] of saying what all the different MariaDBs are because when someone uses the term MariaDB [00:35.640 --> 00:37.200] it can mean a lot of different things. [00:37.200 --> 00:42.280] So there's MariaDB Server which is the software kind of everyone knows, there's MariaDB Corporation [00:42.280 --> 00:48.360] which is the kind of for-profit entity that does all the support, consulting, they do [00:48.360 --> 00:51.360] SkySQL, Max Scale, etc. [00:51.360 --> 00:57.240] Then there's the Foundation which is a non-profit entity, we're funded by kind of lots of different [00:57.240 --> 01:04.360] third party companies and we are there to essentially continue the MariaDB source code [01:04.360 --> 01:08.280] for the community essentially. [01:08.280 --> 01:12.440] So bit of a weird job title, Chief Contributions Officer. [01:12.440 --> 01:16.720] So I'm going to explain it using the pillars of the MariaDB Foundation and how they apply [01:16.720 --> 01:17.720] to my roles. [01:17.720 --> 01:23.560] So this and the MariaDB Foundation are openness, adoption and continuity. [01:23.560 --> 01:29.280] And on the continuity side I try and make all the kinds of different contributions easier [01:29.280 --> 01:34.520] for the community to contribute by reducing the kind of time between opening and closing [01:34.520 --> 01:43.300] pull requests but not on the cost of quality or communications to the contributor. [01:43.300 --> 01:47.360] On the openness side we create and publish metrics, I'll be talking about those a little [01:47.360 --> 01:55.600] bit but essentially it's so you can see exactly what is going on with the community contributions. [01:55.600 --> 02:04.600] And on the adoption side we work with communities such as operating systems and also end applications [02:04.600 --> 02:10.280] such as WordPress that use MariaDB to make sure that we can integrate well with them [02:10.280 --> 02:13.840] and grow adoption that way. [02:13.840 --> 02:17.800] So there are lots of different types of contributions, when people hear the word contribution they [02:17.800 --> 02:20.920] usually think of code contributions and those are the ones I'm mostly going to be talking [02:20.920 --> 02:21.920] about today. [02:21.920 --> 02:27.240] But there are lots of others that are important, you know funding for a non-profit kind of [02:27.240 --> 02:33.240] foundation is really important, it helps us kind of grow the community around everything. [02:33.240 --> 02:38.280] Documentation is really important, if you can't contribute code then contributing documentation [02:38.280 --> 02:41.280] is quite useful for us. [02:41.280 --> 02:48.960] See I say this because we have a Zulip, we have people asking questions on Stack Overflow, [02:48.960 --> 02:55.640] Reddit, we have a community Slack, we have mailing lists etc. and the small foundation [02:55.640 --> 02:59.440] can't get to everyone and everywhere so you know if you know how to answer a question [02:59.440 --> 03:06.880] then you know it's a contribution to kind of reply and would love you for it. [03:06.880 --> 03:16.160] And so I grew up in England, we suck at languages, I barely speak English, it's terrible. [03:16.160 --> 03:21.200] So any help we can get with translating error messages, things like that is really useful [03:21.200 --> 03:27.080] to us and we're working on making that a bit easier on a workflow point of view. [03:27.080 --> 03:32.320] And then usage, bug reports, feature requests, actually using the thing and telling us what [03:32.320 --> 03:36.480] you like, you don't like, what's broken, what's not broken, what you want in there. [03:36.480 --> 03:39.800] That's a contribution and that's really useful to us as well, just as much as a code contribution [03:39.800 --> 03:43.000] is. [03:43.000 --> 03:48.360] So going a bit further into non-code contributions, I'm going to talk a little bit about Intel [03:48.360 --> 03:51.960] who's a sponsor of ours. [03:51.960 --> 04:01.920] They do lots of non-code contributions, sorry morning, and they can't really do that many [04:01.920 --> 04:05.680] code contributions due to some legal stuff that they have to go through every time they [04:05.680 --> 04:06.680] contribute code. [04:06.680 --> 04:12.120] But they are doing things like they're constantly benchmarking MariaDB against their current [04:12.120 --> 04:16.600] and upcoming hardware and feeding back the information to us of what's working, what's [04:16.600 --> 04:20.960] not working, what hardware combinations are working, what's not working. [04:20.960 --> 04:25.040] And when they do spot some kind of regression on some new hardware or something like that [04:25.040 --> 04:30.680] or there's a release that's caused a regression on their hardware, they will dig deep and [04:30.680 --> 04:35.200] tell us where to look in the code, what they've spotted and then our engineers can then work [04:35.200 --> 04:36.720] on improving that. [04:36.720 --> 04:43.200] So they've worked a lot with Marco in ADB, I'm sure he's in here somewhere, to improve [04:43.200 --> 04:46.280] the performance certainly in 10.6 recently. [04:46.280 --> 04:50.840] They do supply us with hardware to test against, so a lot of the billboard infrastructures [04:50.840 --> 04:54.760] on Intel hardware, they've given us financial support. [04:54.760 --> 05:00.000] And Steve Shaw from Intel is on the board for the MariaDB Foundation. [05:00.000 --> 05:03.840] So there will always be things you can do to contribute even if you can't contribute [05:03.840 --> 05:06.560] code to MariaDB. [05:06.560 --> 05:08.160] Why contribution is important? [05:08.160 --> 05:13.080] Well, so we get a more diverse input from each life experience. [05:13.080 --> 05:18.400] So if a project is built by one team in one country, in one office, for example, you're [05:18.400 --> 05:26.120] not going to get a diverse feel of not just culture, but use cases, et cetera. [05:26.120 --> 05:32.520] So I think it's really important to get contributions for a wide group of people. [05:32.520 --> 05:37.560] You get to direct a project the way the users want rather than being led by one single entity, [05:37.560 --> 05:39.480] one single corporation. [05:39.480 --> 05:45.120] So if a corporation says, OK, all the money is here, they're going to put all the resources [05:45.120 --> 05:50.120] to develop those features and it might not be what somebody using WordPress wants, for [05:50.120 --> 05:51.120] example. [05:51.120 --> 05:56.480] You're fixing bugs and things that are important to you, and I think that's quite important. [05:56.480 --> 06:00.160] And you're building a real community around the project. [06:00.160 --> 06:03.680] So it wouldn't be a fuss to me if I don't talk about Drizzle. [06:03.680 --> 06:13.360] For those who don't know, Drizzle was a database server, it was a fork in MySQL 6 back in 2009. [06:13.360 --> 06:19.600] It started in some micro systems and it was designed to be a micro kernel kind of fork [06:19.600 --> 06:26.600] with loads of different plugins optimized for web and cloud usage. [06:26.600 --> 06:29.880] It eventually died, so that's why you probably haven't heard of it. [06:29.880 --> 06:37.520] But in 2009, we had a talk where we said we want 50% of the code contributions to come [06:37.520 --> 06:42.600] outside of some micro systems, and we kind of met this goal in a unique way. [06:42.600 --> 06:45.080] Oracle bought some and fired everybody. [06:45.080 --> 06:54.720] So we did meet the goal and everyone went to Rackspace, but my point is, MariaDB Server [06:54.720 --> 06:59.000] has more external contributors than internal contributors. [06:59.000 --> 07:06.000] So the corporation has, in 2022, 36 code contributors, there's eight from the MariaDB Foundation, [07:06.000 --> 07:08.160] and there were 68 code contributors elsewhere. [07:08.160 --> 07:12.360] Now, obviously, those contributors are not working full time on the code base, but it [07:12.360 --> 07:16.080] does mean that they kind of fix the problems that are important to them. [07:16.080 --> 07:19.760] And it's a pretty impressive stat, I think. [07:19.760 --> 07:24.280] And we had similar stats in 2019, you know, kind of something happened in 2020, can't [07:24.280 --> 07:28.960] think what, that kind of, of course it was kind of implied, but yes. [07:28.960 --> 07:35.880] Also, many of the contributions we've got from China, and that was visited a lot before [07:35.880 --> 07:36.880] the COVID. [07:36.880 --> 07:37.880] Yeah. [07:37.880 --> 07:41.640] So if you don't see contributors, they forget. [07:41.640 --> 07:42.640] Exactly. [07:42.640 --> 07:47.600] So as Monty said, COVID hit, China kind of caused the stats to dip a little bit, and [07:47.600 --> 07:48.600] things like that. [07:48.600 --> 07:53.640] They started to get back up again in 2021 and 2022 has probably been our best year ever, [07:53.640 --> 07:57.680] and I think we got some really big stuff lined up for 2023 as well. [07:57.680 --> 08:02.640] So the actual stats for 2022 are on screen right now. [08:02.640 --> 08:05.960] So corporation, obviously, is the biggest contributor. [08:05.960 --> 08:09.040] They pay a lot of full time developers to work on it. [08:09.040 --> 08:12.920] We have a smaller number in the foundation of full time developers and some people who [08:12.920 --> 08:15.520] work part time on the code and things like that as well. [08:15.520 --> 08:19.760] So even I contribute a little bit, but now we're near as much as everyone else, you [08:19.760 --> 08:23.160] know, at most one day a week, so it's not the huge amount. [08:23.160 --> 08:29.440] And then other contributors kind of outside of the MariaDB circle, pretty much on par [08:29.440 --> 08:33.640] with what the foundation contributes, so pretty good. [08:33.640 --> 08:38.480] So we use Git DM, which is called Git Data Miner, to actually process the Git commit [08:38.480 --> 08:40.160] stream to generate this. [08:40.160 --> 08:44.720] And I've actually open sourced the tooling that does all this, and it has all the kind [08:44.720 --> 08:46.960] of metadata in there to generate this. [08:46.960 --> 08:53.320] So you can actually break it down by user, by entity they work for, et cetera. [08:53.320 --> 08:57.280] And if you find that I've made a mistake on identifying someone, you can actually open [08:57.280 --> 09:01.800] a pull request on that and change the data accordingly. [09:01.800 --> 09:06.680] So it's kind of open in that respect as well, if you see what I mean. [09:06.680 --> 09:09.680] Git Data Miner was something that was generated, it was created for the Linux kernel. [09:09.680 --> 09:13.920] We tweaked it a little bit so we can count hackers and things like that, but yeah, it's [09:13.920 --> 09:16.640] essentially the same tool. [09:16.640 --> 09:18.200] We have a script to generate pull requests. [09:18.200 --> 09:23.600] I know this chart is going to be difficult to see on the screen, but kind of the trend [09:23.600 --> 09:25.360] is the important part. [09:25.360 --> 09:28.840] So this scrapes GitHub for weekly pull request metrics. [09:28.840 --> 09:35.680] So the X axis here is weak numbers, and then the Y axis is the number of open pull requests. [09:35.680 --> 09:39.520] So the bottom is 80, the top is 120. [09:39.520 --> 09:41.200] Part of my job is to help bring this down. [09:41.200 --> 09:43.160] I have been failing. [09:43.160 --> 09:47.280] I will be working on that quite a bit in 2023. [09:47.280 --> 09:48.280] So I'd run. [09:48.280 --> 09:53.360] You should also add how many actually close to that one, how many are open. [09:53.360 --> 09:58.800] I do have that, but showing that on this chart was getting very messy. [09:58.800 --> 10:02.560] So it's hard enough just showing this. [10:02.560 --> 10:08.400] We do close a hell of a lot of pull requests as well, and we don't just go in and say, [10:08.400 --> 10:09.520] no, that's rubbish close. [10:09.520 --> 10:13.480] We tend to talk to people through the pull request, and that's why some of us stay open [10:13.480 --> 10:16.480] quite a long time. [10:16.480 --> 10:22.000] So in the metrics future, I kind of want to break down the commit contributions by module, [10:22.000 --> 10:23.000] engine, et cetera. [10:23.000 --> 10:28.280] So we know how many contributions are coming to InnoDB, how many to connect engine, how [10:28.280 --> 10:33.400] many to ROXDB, et cetera, so that we can track that kind of usage. [10:33.400 --> 10:40.600] I want to track the average time to merge pull requests, median and mean, I guess, probably [10:40.600 --> 10:44.680] median because we've got some that have been open a couple of years and some that only [10:44.680 --> 10:49.440] stay open a week or two, for example. [10:49.440 --> 10:50.440] But we'll track that. [10:50.440 --> 10:53.160] We'll bring it down. [10:53.160 --> 10:54.160] Buildbot contribution metrics. [10:54.160 --> 10:57.200] So we use buildbot for continuous integration. [10:57.200 --> 11:01.000] We do get pull requests through that, contributions through that. [11:01.000 --> 11:04.920] So we'd love to track that kind of stuff. [11:04.920 --> 11:06.400] More community-wide metrics. [11:06.400 --> 11:07.480] So we're talking Jira. [11:07.480 --> 11:11.480] We're talking Stack Overflow Reddit metrics, et cetera, like that, capturing those kind [11:11.480 --> 11:18.240] of things and publishing along with the quarterly stats that I already published on meridb.org. [11:18.240 --> 11:20.920] And if there's any other metrics you want to see, let us know. [11:20.920 --> 11:25.280] Contact us because we are happy to generate them. [11:25.280 --> 11:28.200] So we'll talk about how to contribute code to Meridb. [11:28.200 --> 11:34.000] I wrote a blog post about this on meridb.org, but there are some basic steps you can follow. [11:34.000 --> 11:38.160] And it kind of helps reduce the round trip time during review. [11:38.160 --> 11:44.960] And also, I don't want you to spend hours, days working on something and opening a pull [11:44.960 --> 11:49.680] request and saying, sorry, this doesn't really fit with what we're doing at all or someone [11:49.680 --> 11:51.120] else has already done this. [11:51.120 --> 11:55.960] And I have to say no, because I don't want to crush people's hopes or anything like that. [11:55.960 --> 12:00.560] So if you follow these steps, it will kind of help reduce that quite a bit. [12:00.560 --> 12:04.000] So the first step is communication, talking to us. [12:04.000 --> 12:07.080] We can guide you through kind of every step of the way. [12:07.080 --> 12:12.000] Meridb team are quite approachable, preferably via Jira and Zulit, but there are other ways [12:12.000 --> 12:13.720] to talk to us as well. [12:13.720 --> 12:17.360] In particular, Vicente Daniel and me at the foundation, there are a list of people at [12:17.360 --> 12:21.280] the corporation I'm sure you can talk to as well. [12:21.280 --> 12:22.800] Tell us what you want to work on. [12:22.800 --> 12:27.160] And if you don't know what you want to work on, there is a beginner-friendly tag on Jira [12:27.160 --> 12:33.120] where we've tagged tickets that should be relatively easy to pick up and work on. [12:33.120 --> 12:35.000] And we can talk you through these. [12:35.000 --> 12:38.400] If there's no Jira for what you want to work on yet, open one and again, talk to us and [12:38.400 --> 12:44.640] we can figure out the best solution for it. [12:44.640 --> 12:45.840] Next step is hacking. [12:45.840 --> 12:47.840] Write some codes. [12:47.840 --> 12:52.960] If you are making a bug fix, it needs to be against the oldest-affected version of Meridb, [12:52.960 --> 12:56.640] so if it affects 10.5 upwards, then against 10.5. [12:56.640 --> 13:00.040] What is the thing that active release? [13:00.040 --> 13:01.040] Yes, active release. [13:01.040 --> 13:03.320] Yes, this is a good point. [13:03.320 --> 13:08.040] Always check the end of life as well for the releases when you do this because we're in [13:08.040 --> 13:14.240] this weird phase right now where we have got, we changed release cycles a couple of years [13:14.240 --> 13:17.680] ago, so some releases are on the old release cycle and some are on the new release cycles [13:17.680 --> 13:21.160] so some in the middle are end of life but some are. [13:21.160 --> 13:25.480] So it's a bit funny right now, but again, you can talk to us about this and we can help [13:25.480 --> 13:27.000] point in the right direction. [13:27.000 --> 13:33.600] The new features always go in the latest development version, which currently is 11.0 for the next [13:33.600 --> 13:34.600] couple of weeks. [13:34.600 --> 13:39.760] When that hits GA, there'll be another release you can bolt things on. [13:39.760 --> 13:42.200] Please stick to the coding standards to the surrounding code. [13:42.200 --> 13:46.480] You'll find that different engines have different coding standards because they've come from [13:46.480 --> 13:47.680] different places. [13:47.680 --> 13:52.720] Connect engine was originally a MySQL contribution that came through to MarineDB and that's got [13:52.720 --> 13:56.640] a different coding standard to say NODB and the core server code. [13:56.640 --> 14:01.840] I've put together a coding standards document which should be merged shortly and that's [14:01.840 --> 14:06.960] just for the core server and at the moment it's descriptive, run and prescriptive, but [14:06.960 --> 14:10.800] we're going to improve on that over time. [14:10.800 --> 14:17.040] Some test cases, we don't want you to write something, us merge it and then us break it [14:17.040 --> 14:18.040] later. [14:18.040 --> 14:22.480] So if you have some test cases in there, A, it proves exactly what you're doing and [14:22.480 --> 14:27.760] B, it means that it will stay like that in the future. [14:27.760 --> 14:32.080] Run the MTR test suite locally because otherwise you might get build bar errors that you don't [14:32.080 --> 14:36.280] expect and it just reduces the cycle a little bit there. [14:36.280 --> 14:40.160] If it's a new feature, help us write some documentation or at least describe what it [14:40.160 --> 14:47.120] does in the JIRA tickets so that we can put that into the knowledge base at a later day. [14:47.120 --> 14:49.520] Next up, pull requests. [14:49.520 --> 14:54.440] When you open a pull request, a form will pop up and filling this in will help us triage [14:54.440 --> 14:56.440] the pull request essentially. [14:56.440 --> 15:02.040] So a lot of your questions about whether this is a bug or a feature, have you added a test, [15:02.040 --> 15:05.440] does this break things, stuff like that. [15:05.440 --> 15:10.280] If it's your first time doing a pull request, something called the CLA assistant will pop [15:10.280 --> 15:11.280] up. [15:11.280 --> 15:15.760] It's not 100% intuitive right now, it's something we need to improve on, but right now it will [15:15.760 --> 15:18.120] pop up and ask you to sign the CLA. [15:18.120 --> 15:23.000] You can click through that and either sign the CLA or tick to say, I want to contribute [15:23.000 --> 15:27.360] under the three clause BSD license or you can just literally put a comment in and say, [15:27.360 --> 15:33.080] I'm contributing this under the three clause BSD license and then we can take it from there. [15:33.080 --> 15:37.600] What will run on the pull request automatically, lots and lots of different builders. [15:37.600 --> 15:45.600] The most important ones will report back to GitHub and show you that if anything has failed [15:45.600 --> 15:50.400] during compiling or testing on lots of different platforms we support. [15:50.400 --> 15:54.760] When we actually go to review it, we'll actually look at the full build list where there might [15:54.760 --> 15:59.440] be some obscure platforms that might have broken in weird ways, but at least it gives [15:59.440 --> 16:04.120] you some idea of what's gone wrong and you can click through and look at the cause. [16:04.120 --> 16:08.960] Again, if you don't understand the error that popped up, we can look at it for you and point [16:08.960 --> 16:12.080] you in the right direction. [16:12.080 --> 16:17.520] Code review process, the MariaDB engineers, both at the Foundation and Corporation will [16:17.520 --> 16:20.240] review, give feedback, advice. [16:20.240 --> 16:24.520] If we think the code is ready, we'll approve it and merge it. [16:24.520 --> 16:28.440] Community members are also welcome to come look at the codes that people have contributed [16:28.440 --> 16:33.720] to it, review it, comment on it, and it's another way you can contribute. [16:33.720 --> 16:37.520] If we are taking time to get to your pull request and we're dropping the ball or something [16:37.520 --> 16:43.320] like that or you need advice, you can tag me at Linus Jedi on GitHub and I will take [16:43.320 --> 16:45.440] a look at it for you. [16:45.440 --> 16:49.520] I'm lagging a bit behind on that because I'm at FOSDM right now, but I will try and [16:49.520 --> 16:51.440] keep up with that. [16:51.440 --> 16:56.840] We have a large backlog right now, so it is very easy for us to miss things. [16:56.840 --> 16:58.560] That is all I have. [16:58.560 --> 17:00.560] Any questions from anyone? [17:00.560 --> 17:01.560] Yes. [17:01.560 --> 17:07.920] Is the Foundation and the Corporation have different release cycles or is that? [17:07.920 --> 17:09.920] It's Foundational Corporation different release cycles. [17:09.920 --> 17:12.120] So no. [17:12.120 --> 17:18.480] At the moment, the Corporation are generating the releases, so the engineers at the Corporation [17:18.480 --> 17:20.680] are generating the releases, if you see what I mean. [17:20.680 --> 17:23.040] The releases you get are generated by the Corporation. [17:23.040 --> 17:30.400] Built by the Foundation, yes. [17:30.400 --> 17:33.360] There's a lot of synergies between the two, which is a good thing. [17:33.360 --> 17:35.840] We want to be working closely with them, if you see what I mean. [17:35.840 --> 17:40.160] But if anything, God forbid, happened to the Corporation, the Foundation existing means [17:40.160 --> 17:47.360] that MarineDB Server will still exist, will still be developed, et cetera. [17:47.360 --> 17:50.760] All right. [17:50.760 --> 17:51.760] Thank you very much. [17:51.760 --> 17:56.760] Thank you.