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