 Okay, it's time to get started. Can we close the doors in the back? All right, everyone. Welcome to the Postgres dev room at Fozdom. First speaker is up is Letitia, who's going to talk about demystifying contributing to Postgres. So let's talk about contributing. Who, in the audience, think he's already contributing to PostgreSQL? Okay So you're wrong because everyone in this room is already contributing. You just don't know it. So let's start. First, I'm Letitia, and Letitia is close enough. No, it's okay. I'm just teasing you. I've been a DBA for PostgreSQL for more than 10 years. In my company at the time, I had to learn some Oracle and SQL Server 2. I also did some DB2, but I don't say it because I don't want to do it again. And you can follow me on Twitter and and That's it. So my actual company is Luxadata. It's based on three pillars. The first one is Postgres, of course, because it's our field of expertise and then we have DevOps because we need information to flow freely because between the developer world and the operational world. So we try to help and then when a customer wants to use the cloud, we're here to help control data and what you share. So here you have me six months ago. I wanted to contribute and first, I didn't know I was already contributing. And I didn't know what to do. I didn't know where to begin. I didn't know what I could do to help and mostly I didn't want to mess up the project. That's so wonderful. So I will first introduce how the community works. What are the projects and tools used in the Postgres community? And after that, I will tell you the story of my patch, which is as you will see, really tiny and after that, we will focus on you and how you can help. So here is a photo taken in 2006. Now the community has grown a lot and you see that there are a lot of nice people. Try to do a drawing to categorize how to help and just keep in mind that one person can be in more than one category. It's not because you choose to do one thing that you can't do another thing. So first you have the core team. It's the center of Postgres QL and then you have committers. Committers are between the core team and other people. Then of course you have developers. Postgres QL is a code project. So there are developers, but there are also reviewer and you should know you don't need to be a developer to be able to read code. And of course, Postgres QL is a serious project. So there is code review. And there are translators. You don't have to be a developer to be able to translate. Then we have advocacy. Advocacy is about advertising. Nowadays, you know, you may have the wonderful project, a wonderful product, but if you don't advertise about it, it won't work. So there is an advocacy group and it's supported by associations and local user groups. What I put in community it's not contributing, but its community is our users. To me, I had discussions because people don't agree and it's okay. Users are part of the community. I know that once you use Postgres QL, you'll fall in love because it's wonderful. So it's not a problem. Once you become a user, you'll take the next further. So the core team. The core team is a five-member team and they act as project managers to Postgres QL. What's important is no one owns Postgres QL. It's totally independent. And the core team is here to take direction and cut discussion where there are too many discussions about one feature or another. Committers. To characterize, you can say that committers are upgraded developers. They still write code, but they have more responsibilities because they are responsible for code quality as they have Git push permission. We will talk about Git later. It's more or less 15 people and they work together to ensure the code keeps wonderful. So developers. So here is a meeting of major developers, but there are a lot of minor developers. Postgres QL code is written in C because it's better for performance, but it's C with a style guide. And you need to comment really a lot. I talked with a developer once and he told me it was the first time he was asked to put three lines of comments for a simple if statement. But it helps keeping the code clean and neat and it's really important. So if you create a patch and you've got a feedback saying you need to comment more, don't be ashamed or anything. It's quite normal and when you will improve your commenting, the patch will be committed. Reviewers. So as I said earlier, you don't need to be a developer to be a reviewer, but some technical background is needed. What you have to keep in mind when you're doing code review is if you don't understand what the code is doing, there is a great probability that others won't understand either. So you may ask, you may send a thing back and asking for how it's working and so on. And after you may say that maybe the comments are not clear enough and so on. Translators. So obviously you don't need to be a developer to be a translator. What's need to be translated in post-waste projects are software messages, documentation of course, but also press releases, websites and so on. So you still need some technical basis because I don't know how you could explain PITR if you don't know what the writer-headlock is, but you don't need to be a developer. So the advocacy. The goal of the advocacy group is to promote PostgreSQL use. It shares information about PostgreSQL as you can see in blog posts, events, or even booths like here in first day. It also helps sending information to media as press release and so on. If you look at postgreSQL.org websites, there are two associations. There is the European Association and the US Service Association. Please consider going to the European Association if you're European as the fee is only 10 euros for two years. So it's quite cheap and you'll help the project this way. Local user groups. It's groups that are created by countries. So in this map, any country in Brown is a country when you will find a local user group. If your country is in white, you're welcome to create one. And also in the map, I tried to put meetups. It's the slonic you see here. Well, I made it in early January and since then I've seen that two or three more meetups were created. So again, if in your city there is no meetup, no postgreSQL user group meetup, you can create one. What's important? Why do you want to meet other postgreSQL users? It's simple because with more brain, you have more solutions. So you can gather with other users and share anything about issues you had, how you solve it, and you will have other point of view and other ways to solve your issues. And you also will share thoughts and use cases and ideas and so on. And when you will find another issue, maybe you will have already the solution because you have already discussed about it with someone who had something similar. So you will be rewarded when you will talk to other people in the community. Let's talk about projects. So in postgreSQL, projects are in Git repositories. I tried to categorize these projects because there are a lot. And in this illustration, the bigger the box, I think the bigger the probability you need to clone that project to contribute. But it's only my point of view, I could be completely wrong. So first, of course, there is a postgreSQL project itself. Then we have a translations project that you can contribute to and contributions and tools. Some have their own Git repositories, so don't be afraid to Git clone them to look at the code and see if you can do something. And that one, I don't think you will clone it. It's only maintenance stuff as CommitFest, the Git repository itself and so on. What I put in packages are of course packages for Linux distributions but also Windows installers and so on. So maybe you would like to contribute to this one. And the last one is about communication, mailing list, websites and so on. So how does it work? PostgreSQL project has a roadmap and it's quite simple. There is one major release per year and one minor release per quarter. But it's a minimum. If there are some security issues or some bugs that we need to fix really urgently, there will be more than one minor release per quarter. The difference between major release and minor release is quite simple. When you do a minor release, you just need to upgrade the binaries and it's okay. For major release, you need to upgrade your data too and that could be a problem. And after that, we have CommitFest. So CommitFest is one month long period of time when most patches are committed. It's as if we were sending a signal to developers to say, stop writing code. We need people to review it because we have a lot. So it happens every two months and we just ended the January CommitFest a few days ago and you will find information in the CommitFest.postgreSQL.org. If you want to review code, you will have to go there and to register as a reviewer and to pick the patches you want to review. Tools. So of course the community relies on tools. First, there are some websites I'm sure you already know, postgreSQL.org, as maybe the wiki.postgreSQL.org or postgreSQL.org slash docs. Sorry. But there is that one that's really great. It's called planet.postgreSQL.org and in that one, you will find blog posts about PostgreSQL, about old feature, about new feature, what's going on in the community. You will find everything here. So postgreSQL community works with mailing list. I know it's quite old-fashioned, but it's stable and it works. So why change it? First, there is the bug submission form you will find in postgreSQL.org. Just please, if you have a security issue, don't set it in the bug submission form because it's public, so anyone can see it. Use that mailing address, so to be sure it's kept private just to leave developers the time to fix it. If you're a newcomer to postgreSQL, maybe you have some question you don't dare to ask because you think it's silly. So there is no silly question in that mailing list. And if you are a more advanced user, you can subscribe to this mailing list to answer. And the last one, the developer list, the hackers list, so just be careful because you will be overwhelmed with mail because these guys are so chatty. They can make more than 50 subjects in the same day and for each subject you can have 10, 20 mails. I think they are always connected and always sending mails to their friends. So maybe you won't have time to read any mail in that mailing list. I don't know if there is a human in her house that has time enough to read any mail in every mail in that mailing list. But you can try. You can pick which subject you want to read. IRC. There is an IRC channel on IRC.freenote.net. So what's good with IRC is there is no history. So if you think your question is silly, don't be ashamed, there is no history. So it's not recorded, it's okay. Last time I checked, there were more than 1,000 people connected at the same time and so that's 1,000 people waiting for your questions. So go on. Twitter, that's brand new. PostgreSQL has a community account. It's simply at PostgreSQL. I use it to stay in touch with what other PostgreSQL users are posting, blog posts and so on and to see a discussion about features and so on. It's quite relevant. And then there are some other ways to stay in touch. There is a PostgreSQL Slack, there is a PostgreSQL Hangout and of course you will meet some people from the community in forums as Stack Exchange or Stack Overflow. And then we arrive to the last tool, the ones that make people be afraid. So don't be afraid. If you think your mastering Git is good for you, well, I will tell you that. My colleagues think my level of Git is ex-KCD. When I see any error, I take my modification apart, I delete my repository and clone again and it works. So don't be afraid. What you have to memorize is Git clone, Git pool, Git diff. And if you want to show off how smart you are, you can use the option Rebase in Git pool. But there is a wiki page for the use of Git in the PostgreSQL project. So you can refer to that page. It's quite well written. So my story. So first, just to be sure, what's a patch? A patch is a piece of software to fix or improve it. So you don't want to make a patch to make PostgreSQL worse. So my story. I was discussing on Twitter with a friend who had an issue with constraint and he had to do an alter table. So as I don't know documentation by heart, I went to the documentation and I saw that there was a missing section in that alter table documentation page. So I found it really easy as it was written in the create table documentation and as discussed with my colleague and one of them told me, oh yeah, I know, I've seen it for years. He told me, hey, why didn't you do anything about that? So first I reported a bug and then as it was in Vaso, there were a lot of guru members of the community so I grabbed two or three of them and I asked them for help. And after that, I could submit my patch. So how to create a patch? First, you have to get clone the repository and to build from source code and as my patch was about documentation, I had to build documentation from source code. So you will find anything you need, everything you need in the Wiki page. After that, I only had to copy pass the missing section from the create table page to the alter table page so quite easy and I will build the documentation from source code and it built. So after that, I had to create a patch. To create a patch, we use git diff. So it seems complicated because you have two Wiki pages. The first one is how to create clean patches for PostgreSQL and the other one is how to format your git diff output. And it's quite complicated. You have to modify something you don't know about and you're afraid you will mess with your git configuration and so on. So I searched and I found that even the best sometimes don't follow instruction and it was so easy to do. Just a git diff, filter diff format context. So what's the difference between a git diff with context and a git diff without context? The difference are the line number which are relative in the wizard context and the indentation that's correct on the right on the with context git diff. After that, you can submit. So to submit, you just need to have your patch and to send an email to the hackers mailing list. Just be sure you answer every question in the submitting a patch Wiki page. And I have a result that was thanks, it's great but there was a method section missing and maybe you could fix that too. And so it was late on Saturday or something like that and so on Sunday I opened my computer to make it but too late, someone else had done it for me. Okay, and what happens next? So the patch had a new version and after that it goes to commit fest with the need review status. After that, that patch didn't build anymore so there was someone else who did another correction so the patch could apply cleanly on the head branch. There was another section missing so someone else, I mean it again, did another version of the patch so that other section missing was corrected and it was ready to be seen by committers and just yesterday it was committed and now I can die because I did something. No, what next? So first I decided to give a conflict about that story because I was too shy to do it earlier I could have done it years ago but I didn't do it and I didn't think I was worth it so my message is you're worth it, you can do it. And after that I did some corrections in there was some spelling errors in the French translation and if you know French people you know that the spelling errors are right as crime in French so I did some corrections and I've been studying the code so if you want to study PostgreSQL code don't do like me, read the readme files. I just had forgotten that one and so after that I submitted for call of papers and every proposal I made was accepted so I had some work to do to prepare my conflict. So let's talk about you, how you can help. I did some ranking because we all know geeks love leveling up so here is your level and you will see how you can level up. So a simple contributor uses PostgreSQL shares his or her experience and answers other questions and sure everyone in this room can do that. It's quite simple. When I say sharing experience it can be blog post, it can be on Twitter it can be with going to meetups to conf talks and so on. When you answer other questions you can go to IRC, you can answer directly in mailing list or in forums so there are a lot of ways to contribute just in the simple contributor but keep in mind that just going to an event to a PostgreSQL event is already a contribution. A great contributor, it's the next level so maybe you can go there I decided a great contributor creates or help organizing a user group or meetup or an event or a great contributor can invest some time or money in a PostgreSQL association and after that you have a super contributor and I'm sure you would like to become a super contributor because a super contributor can report bugs so I'm sure you can report bugs can create patches and as you see you don't have to be a developer even to create patches and can review patches. So to conclude I want you to memorize two things first you wash it and you can do it and then anyone can patch if I made it really I'm not a genius so if I did it you can do it it's really that simple and so joins the community so I just like to thank my guru Dimitri, Greg, Vic, Robert and Alvaro because I took a lot of their time and patience and by the way my company is hiring so if you're interested just write a mail and we'll take some questions. Questions? Thank you very much for a great talk one quick question around the documentation side you were contributing to the core documentation in the sort of standard bundle with the software the Postgres Wiki there's a Postgres Wiki like it's wiki.postgres.org is that done by Git? No, it's not in the same place the wiki page is in another place But is that part of the core project? No, it's not part of the core project I think it's what I put in communications So I can see that there's the rare gap there but there's big gaps in the Postgres Wiki about what newbie users need and that would be nice if I could get more a bit more love and attention Thank you very much But just ask and you will have permission to make it better Yeah, wiki.postgres.org is managed by the same Postgres infrastructure team and so if you've got a community account and you want to edit on the Wiki you just send an email to the pgsql www.list and request editor permission and give us your login name and someone will give you editor permission on the wiki You said that anyone can register for review and patches Yeah How do you determine if someone who registers for that is actually capable of doing the actual review So if someone says this is okay how do you know that it's actually okay There is more than one reviewer So normally you don't have that risk with more than one people and in the community everyone knows everyone So if you mess with the reviewing first you will be told really gently but after we will try to help you improve your reviewing But it's not a requirement for some senior level Postgres to have a stamp of approval on it No, it isn't needed Okay If you look at Postgres QL code you can read it as any book because there are so many comments you can just switch the code lines and everything ultimately has to be reviewed by a committer too Yeah, yeah Thank you Testing one, two, three Is that slide enough in the back? Yeah, that's all Devram, can you hear me back there? He's ignoring me Devram, how's the volume? How is the volume? Is the volume good enough? Yes? Yeah?