Takeaways from the First 6 Months of Hacking on Postgres Melih Mutlu @melihmtl PGConf.EU 2022, Berlin

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.

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

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

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

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.

Concerns about starting with • What do I know about databases? • Are there enough opportunities? • Looks a bit scary

Okay, Let’s contribute to Postgres

But how to start?

How to start Some resources: • Wiki https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F • Previous talks • Blog posts

How to start? Some concepts that were new to me: • Patch • Alright, git can create a patch.

How to start? Some concepts that were new to me: • Mailing list • Wait, are they sending changes via e-mail?

• Mailing lists are used for many open-source projects • Not used to mailing lists if new in open-source

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.

Where to start

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

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.

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.

Keep in mind • Start with something small. • Discuss your idea with hackers first. • Go to hackers with some metrics to explain your reasoning.

Start coding…

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.

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

Where to get help • Documentation • Comprehensive But: • User focused

Where to get help • Comments • Helps a lot to understand the code But: • Not everywhere • May omit information sometimes

Send the patch to mailing list

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/

The patch is ready now • Congrats on your first patch! • I guess someone will review it. • Right?

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!

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…

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.

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.

Patch reviews should be a good way to learn about Postgres!

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?

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//

Wait, how would anyone know?

Is the work visible? • You have contributed to Postgres! • But how can anyone see my colors of productivity?

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/

Last words… • Each patch has its own journey. • Please share your tricks that can be useful for others.

Thanks for listening! Twitter: @melihmtl