The story of how I came to contribute to Postgres is that I got tired of working at a software consultancy where I had worked for 3 years, 2 years during college, 1 year full-time. I had always more envisioned myself as an open-source systems software guy. I found a job at Micron working on an open-source storage engine. It kind of felt like luck to have found that job to be honest, but I felt like the job description was written for me, so I applied. I worked on that project for 2.5 years and loved it. Unfortunately, Micron laid off my entire team back at the end of February. I began searching for a job, and eventually received an offer from MongoDB to work on the C/C++ drivers, but that was rescinded. Then, I really started to lean into my network, and one guy I knew from #mesonbuild on Libera.Chat/Matrix worked on Postgres, so I messaged him and asked if there were any positions open in the Postgres space for someone with my background that he might be aware of. He told me that Neon was hiring, so I sent an application to work on their storage engine, but in the initial interview, my eventual manager thought that I would fit better in the new Postgres team they were forming, which would contribute upstream to Postgres. I am very appreciative to Neon for taking a chance on me.
The topic of this blog post is interesting because it just came up during some discussions with other young Postgres contributors at PGConf NYC. Some points that we brought up:
- It is hard to get patches looked at, even small ones. With better name recognition in the community, comes more patch reviews it seems, which is most likely the case in most projects, but still, it is a circular issue.
- The organization of the Postgres mailing list is not very good. You are forced to drink from the firehose that is pgsql-hackers, whereas the LKML is organized into various subsystems. Modern code forges have value in that you can subscribe to certain tags on PRs/issues, which isn't the case with the current state of pgsql-hackers.
- Adding things to a commitfest is a little burdensome. The only way to get a patch through the entire Postgres CI is adding it to the commitfest, and even then, you have to be proactive about checking it, or hope that a committer will tell you to look at the CI failure.
- Bug reports are also sent to a mailing list (pgsql-bugs). There is no equivalent to the Linux bugzilla for Postgres for instance.
- Patches are sent as attachments to emails, and not necessarily git-format-patched either, whereas the LKML uses git-send-email exclusively from what I can tell.
All in all, it kind of seems like tooling in the Postgres contributor community works best for those that have been ingrained in it for 15+ years, which I guess is the case for most things. I don't want this to turn into a "Use GitHub/GitLab" post. Let it be known that I actually think email is the superior way to communicate about patches, but the tooling around the mailing list could improve. Everything seems very disjoint. SourceHut, I think, has done a good job of making mailing list development more approachable for the everyday contributor. Issues, mailing lists, CI/CD, and repositories are all connected to each other. There aren't separate services like they currently are for Postgres.
This comment is probably worth a blog post of its own at some point, but I'll end it here. If you are also new to contributing to Postgres, perhaps we can share experiences. Email me at tristan <at> neon.tech or tristan <at> partin.io. Another Postgres contributor that I talked to thought it might be useful to have monthly meetings among non-committer contributors where we can talk about the patches we are working or have posted in order to get reviews from peers.