I agree that this is a significant issue. I'm less sure about the "better name recognition" bit, I feel there's also a significant drop off at the other end. But that might just be biased by my level of experience.
> - 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.
Yep. And it has gotten a lot worse in the last couple years, I'd say.
> - 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.
My main reason to reply here was this: You can also enable CI in your repository: https://github.com/postgres/postgres/blob/master/src/tools/c... - that's the same CI that happens for commitfest entries.
> - Bug reports are also sent to a mailing list (pgsql-bugs). There is no equivalent to the Linux bugzilla for Postgres for instance.
Yep, I hate this. I loose track of things all the time, I'm way too easily distractable. I think the kernel bugzilla is pretty useless, but it's not that hard to do better than that.
> - 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.
I find lkml style patch handling bad as well, particularly with every patchset revision getting its own thread. Very easy to loose track.
> 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 personally wouldn't say it works particularly well, even after participating in development for about 15 years... I'd also say that the development process has evolved some in that time, just not as far as it'd be good. It's a lot of hard work to get a community as grey-beardy as the PG community to evolve. Not impossible, but ...
> I don't want this to turn into a "Use GitHub/GitLab" post.
Personally I strongly dislike using either for nontrivial work. But: I still think we ought to accept PRs/MRs via one of the two, just to make it easier for newer contributors. But it isn't just my call...
> 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.
I suspect you'd actually have a hard time finding more than 2-3 people disagreeing with that notion. One of the problems is that many of us end up preferring to spend time hacking on postgres than on development-process tooling / integration....
I need to get around to this...
> I find lkml style patch handling bad as well, particularly with every patchset revision getting its own thread. Very easy to loose track.
This is a good point, but if it works for the largest open-source software project in the world, I think it could work for Postgres too. I find that being able to reply inline to an email without having to copy-paste huge sections of an attachment is pretty valuable.
> One of the problems is that many of us end up preferring to spend time hacking on postgres than on development-process tooling / integration....
Completely agree, which is why I think we need to investigate migrating to a self-hosted SourceHut instance or something, so we can just use the tools that are provided by a company whose job it is to write those tools.
> This is a good point, but if it works for the largest open-source software project in the world, I think it could work for Postgres too. I find that being able to reply inline to an email without having to copy-paste huge sections of an attachment is pretty valuable.
I had actually forgotten that issue, having scripted it years and years ago to be automatic. My beef around this is gmail attachment being randomly ordered...
https://git.sr.ht/~tristan957/dotfiles/tree/master/item/aerc...
mime_lookup application/octet-stream application/x-gzip application/gzip application/x-bzip2 binary/octet-stream application/x-download invalid/octet-stream
Being a long-timer in the Postgres community, I was hesitant to enable this. But trust me, the 5 minutes you'd spend enabling this would be completely worth it. The breakage reports for your commits, if any, are worth it because they save community's time finding and reporting those bugs to you.
I only wish this system was not tied to GitHub and CirrusCI, though.
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. But 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. SourceHut, I think, has done a good job of making mailing list development more approachable for the everyday contributor.
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.