Takeaways from the First 6 Months of Hacking on Postgres | PGConf EU 2022 | Melih Mutlu

Postgres is growing – in usage, in popularity and in the size of the community. And as usage grows, more and more people are wanting to contribute to PostgreSQL as well. However, getting started in Postgres development is more than simply coding a feature or fixing a bug. It’s understanding the codebase, the community, the processes.

Melih is a Postgres newbie and a developer in the early stages of his career who has only been working with Postgres for 6 months. In this talk, he will share his first experiences with Postgres. What were the difficulties for him? What made it easier to hack Postgres? Some tips for getting started and what we can do as a community to improve the process. Finally, we will end with how he ended up with my first contribution to logical replication. If you’re a new developer wanting to contribute to Postgres or want to hear how my journey is going as a newcomer, please join him.

Transcript

1. Takeaways from the First 6 Months of Hacking on Postgres Melih Mutlu @melihmtl PGConf.EU 2022, Berlin
2. About Me • Melih (@melihmtl) • Software Engineer • Joined Microsoft in 2019 as new grad • Worked on Hyperscale Citus (Cosmos DB for PosgtreSQL now) • In 2022, switched to Open-source Postgres team at Microsoft • Working full-time on contributing Postgres as part of my job.
3. In this talk You will witness a beginner’s journey of sending a patch for Postgres Goal: • Helping newcomers like me. • Feedback to community about the onboarding process. Mostly based on (but not all) my experiences
4. Spoilers! Where did I end up after this first 6 months: • Still working on Postgres. • Sent 5 patches so far. • 2 of them are committed • CI, logical replication, pg_buffercache
5. Outline • Why contribute to open source & Postgres • How to start with development • Where to start • Working on a patch • Coding • Sending to mailing list • Dealing with reviews • Reviewing a patch
6. Why contribute open-source & ? • Open-source software is cool! • Numerous exciting projects to work on. • It’s a plus and looks good on resume. • Postgres has lots of users and getting even more popular.
7. Concerns about starting with • What do I know about databases? • Are there enough opportunities? • Looks a bit scary
8. Okay, Let’s contribute to Postgres
9. But how to start?
10. How to start Some resources: • Wiki https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F • Previous talks • Blog posts
11. How to start? Some concepts that were new to me: • Patch • Alright, git can create a patch.
12. How to start? Some concepts that were new to me: • Mailing list • Wait, are they sending changes via e-mail?
13. • Mailing lists are used for many open-source projects • Not used to mailing lists if new in open-source
14. How to start? If you’re scared away by how things work in Postgres Keep in mind that: • Git does the work for patches. • Don’t get too overwhelmed when writing an e-mail. • Yes, it goes to hundreds of inboxes. But, people don’t read every e-mail.
15. Where to start
16. Where should I start first? • Is there a todo list? • https://wiki.postgresql.org/wiki/Todo • Bug list? • pgsql-bugs? (another mailing list) • What’s there for beginners? • [E] -> easier to implement • Only 3 [E]’s
17. What could have helped? Resources that show the way to newcomers for their first patch would be helpful • More beginner-friendly labels on tasks. • Easier way to keep track of bugs.
18. How I picked my first tasks • Pulled the Postgres code and tried to build it with different options. • Read the docs and noted places that might be improved. • Discussed with Postgres committers in my team.
19. Keep in mind • Start with something small. • Discuss your idea with hackers first. • Go to hackers with some metrics to explain your reasoning.
20. Start coding…
21. Be aware! • C is not the easiest programming language. • Especially you haven’t used it again after CS 101 course in university. • Postgres has its own way to do some stuff. • You may not find your answer by googling.
22. Where to get help • Community • Mostly welcoming and helpful to newcomers • Archived knowledge on mailing list But: • Hard to get an answer if you’re not known
23. Where to get help • Documentation • Comprehensive But: • User focused
24. Where to get help • Comments • Helps a lot to understand the code But: • Not everywhere • May omit information sometimes
25. Send the patch to mailing list
26. But before anything Here are some mistakes I did with my patches: • Comments • Documentation changes • Tests • Add new one if needed • Run CI • pgindent • Commit message http://cfbot.cputube.org/ https://cirrus-ci.com/github/postgres/postgres/
27. The patch is ready now • Congrats on your first patch! • I guess someone will review it. • Right?
28. Okay, now what? Your patch may wait there in silence… for a really long time. Don’t forget to create commitfest entry for your patch!
29. Suddenly, got a feedback • Addressed the issues mentioned • Then, I got more reviews • I didn’t understand what they wanted • I can always ask, they’re nice people. • Continued to update the patch as reviewers wanted more changes • Reviewers began to discuss more stuff • And, I got lost…
30. Tips for better review experience • Remember my mistakes with patches. Don’t do those! • Accept that you will have to make a lot of changes. • Be prepared to wait. • Be professional and polite in the mailing list. • One hacker saying that it’s a bad idea does not mean it’s bad. • Think about the scope of the patch beforehand. • If no feedback is there yet, update the patch by rebasing, fixing minor typos, adding a new comment. Then, gently ping the thread.
31. How to improve the patch experience • Simplify the process of creating and sending a patch. • Provide reviews with more beginner friendly explanations. • State explicitly if you’re waiting something from author. • Stay focused on the patch in the patch’s thread. • The faster patch process is, the more newcomers stay motivated. • Keep being professional and polite in the mailing list.
32. Patch reviews should be a good way to learn about Postgres!
33. What’s nice about patch reviews? • Increase your knowledge about a part of the codebase. • See how experienced hackers code. • Better code may reduce review cycles for the next patch. • More reviewers help to solve long waiting times issue for new patches. • Wouldn’t this be great for everyone?
34. My biggest struggle with patch reviews • I’m used to review code on platforms with nice looking UI Navigating to GitHub branches created by cfbot on helps. https://github.com/postgresql-cfbot/postgresql/tree/commitfest/<cf-no>/<patch-no>
35. Wait, how would anyone know?
36. Is the work visible? • You have contributed to Postgres! • But how can anyone see my colors of productivity?
37. Is the work visible? • Attending conferences, meetups etc. • Publishing blog posts about your work. https://www.citusdata.com/blog/2022/09/30/how-to-add-more-environments-to-postgres-ci/
38. Last words… • Each patch has its own journey. • Please share your tricks that can be useful for others.
39. Thanks for listening! Twitter: @melihmtl