FOSDEM/PGDay 2025 Developer Meeting

PostgreSQL Developer Meeting 2025 at FOSDEM PGDay

Schedule

Time	Studio 4
Thur 9:00-9:15	Welcome and Introductions
Thur 9:15-10:30	Commitfests, process and tooling (Peter Eisentraut, Jelte Fennema-Nio, Daniel Gustafsson)
Thur 10:30-11:00	Coffee
Thur 11:00-11:30	Where are we on the path towards threading (Heikki Linnakangas)
Thur 11:30-12:00	ABI stability (Peter Eisentraut)
Thur 12:00-12:30	Rust in extensions and in core (Peter Eisentraut)
Thur 12:30-13:30	Lunch
Thur 13:30-14:00	An update on the mentorship program (Robert Haas)
Thur 14:00-14:30	Additional toolchains in the test harness (Jacob Champion)
Thur 14:30-15:00	Alternatives to user mailinglists (Peter Eisentraut)
Thur 15:00-15:30	Patch Triage
Thur 15:30-16:00	Tea
Thur 16:00-17:00	Patch Triage

Participants

• Álvaro Herrera
• Andrew Dunstan
• Bertrand Drouvot
• Bruce Momjian
• Christoph Berg
• Daniel Gustafsson
• Dave Cramer
• Dave Page
• Devrim Gündüz
• Jacob Champion
• Heikki Linnakangas
• Jeff Davis
• Jelte Fennema-Nio
• Magnus Hagander
• Matthias van de Meent
• Nathan Bossart
• Peter Eisentraut
• Robert Haas
• Tomas Vondra
• Vik Fearing

Notes/Minutes

CF app and process

• Peter Eisentraut - We have been running commitfests without a commitfest manager for the past few months and it seems to be going quite well
• Robert Haas - I recently went over the commitfest app and it was absolutely awful, it took at least 30 minutes per patch for me to be able to say anything about it's current state and where it could go - what the blockers were etc. These were complicated and the commitfest is full of patches which are complicated. If it took me half an hour it will likely take even longer for a commitfest manager who isn't used to reading -hackers. It's a terrible experience since we have accumulated a lot of patches which to a large degree aren't going anywhere
• Bruce Momjian - Fedora has a bugtracker and just delete it all at a release for things to be resubmitted
• Robert Haas - Using the commitfest app to find patches to work on is a terrible experience
• Nathan Bossart - I actually find the commitfest app a useful tool for finding things to work on
• Robert Haas - If we want so scale postgres development and the community 4x the current processes doesn't scale. How do we communicate that a patch looks hopeless? If you show up with a good patch, or a good idea, there is a good chance of getting it committed but we dont have a process to tell someone "no". A really bad idea usually gets shot down quick, and good things go through easily, but the big middle tier takes a lot of work and time and is very hard
• Dave Cramer - We should be trying to help contributors to get the patch in the right shape before it even gets to the list
• Robert Haas - We can absolutely do a lot more there
• Matthias van de Meent - It's not just about education, committers are not being assigned to, or responsible for, subsystems which is a problem. It's difficult for anyone new to know whom to approach with their patch or idea
• Robert Haas - No formal assignment of responsibility will happen, so anyone new needs to figure out who to talk to which must be really hard
• Jeff Davis - `git blame` is pretty much all we have for finding which committer is active in which subsystems, but it's not an ideal way of figuring it out
• Matthias van de Meent - Interests also shift over time which makes that approach even harder
• Peter Eisentraut - How about a wiki page describing responsibilites, or interests, to start with?
• Matthias van de Meent - A wiki or the main website listing committers?
• Nathan Bossart - Maybe an email alias for an interest group could be a good way to reach subsystem maintainers?
• Heikki Linnakangas - What are we trying to achieve with this list of names?
• Robert Haas - There are no formal maintainers, anyone can commit anywhere so whatever we write is sort of useless
• Heikki Linnakangas - Right, it could still be useful for someone new
• Robert Haas - It's probably a good idea to document it even though it might not solve the problem
• Christoph Berg - The main problem is the other stuff with no clear owner
• Heikki Linnakangas - If you submit a patch for a subsystem and none of the "maintainers" of the subsystem responds, what to do?
• Bertrand Drouvot - Documenting can also help us find underrepresented subsystems
• Heikki Linnakangas - One problem is that we dont have clear boundaries between subsystems
• Matthias van de Meent - Patches can, and often do, fall into many subsystems - the categories of the Commitfest app aren't a particularly good set of delineations
• Heikki Linnakangas - Maybe we should get rid of the categories?
• <many> A discussion on tags vs categories ensued without really reaching any conclusions other than the two having different characteristics, both of which are desired
• Robert Haas - Circling back, booting everything out at the end of each Commitfest would be the best thing - stale stuff will age itself out on its own when the author or the theread lose interest. We also need to remove all manual steps
• Dave Page - We said the same thing in 2008, lets not move things along
• Robert Haas - We try to be nice to everyone, noone want's to be that guy, so the commitfest manager manually moves every patch along at the end of the commitfest
• Heikki Linnakangas - I didnt even realize we did that
• Bruce Momjian - If we dont have commitfest periods we cant remove anything at all
• Robert Haas - We need some periodic cycles for it to work
• Peter Eisentraut - If we limit moving the patch forwards to the author doing it then stale patches would die
• Heikki Linnakangas - How about forcing a justification to be entered when moving a patch?
• Robert Haas - Prohibit moving unless there is an email to -hackers which describe why it should be moved and what the next steps are
• Peter Eisentraut - New authors come with a patch to the list, and then we tell them to go to the CF app, and then their patch will age out. That's not a good experience, how will we handle that?
• Magnus Hagander - This is why we started the CF app process, to keep track of patches like that
• Nathan Bossart - We have too many hoops to jump for new contributors - we need less hoops even if if that means removing hoops which currently makes commmitters lives easier
• Peter Eisentraut - A lof of patches are trivial, perhaps a new status for "need no meaningful review"?
• Jacob Champion - But who will change the process? We have raised the issue for years and nothing happens
• Christoph Berg - Asking authors to confirm they are still interested isn't terrible
• Robert Haas - We tell new contributors to review patches but where should they start? How should they find patches to work on? The experience isn't good now so changing isn't likely to make anything any worse than it already is
• Bruce Momjian - We dont instruct authors how to document their patches regarding where the blocker is
• Robert Haas - Experienced authors do that automatically - but noone knows that and we don't tell new contributors to do that
• Bruce Momjian - Right, we dont tell people that, the Commitfest app should show what the blocker is per patch
• Heikki Linnakangas - AI \o/
• Bruce Momjian - If the CF app would show state and blockers we dont need to spend 30 minutes reviewing the thread
• Peter Eisentraut - This is probably a good time for Jelte to demo what he has been working on
• Jelte Fennema-Nio proceeds to demo what he has been hacking on:
  • <many>: It should show the diffstat of the entire patchset squashed
  • <many>: The first patch column makes no sense
  • Bruce Momjian - the blocker need to be shown to help users take action - it's hard
  • Peter Eisentraut - the status doesnt help, so we should refine the status
  • Robert Haas - the Commitfest app inevitably has the same problem as any bugtracker, things are never up to date,
  • <many>: freeform text field in the app would help - but can go stale just as anything else - noone will volunteer to update it
  • Tomas Vondra: We can pin emails on a patch to
  • Magnus Hagander: Thats why added annotating emails
  • <many>: it's not enough
  • Magnus Hagander: The design requirement at the time this as built was for the app to never own any information or data, only point to data present elsewhere. Maybe this needs to be revisited, but that's why it does things the way it does
  • Peter Eisentraut: I think we should revisit that, owning meta information is fine
  • Bruce Momjian: Changing the blocker in the app should reply to the thread with the new stauts
  • Christoph Berg: Combining this with a changelog on the patch page, changing the state requires describing why
  • Robert Haas: There should be less manual steps, if we rely on people updating state we are screwed
  • <many>: A one-line summary can probably be made to work
  • Robert Haas: It wont work
  • Heikki Linnakangas: We can still try it..
  • Peter Eisentraut: Make committer in the Commitfest app searchable
  • <many>: Signing up as committer is good, but will "scare" away others thinking that they don't need to do anything since committer X is taking care of it, and then we are back to the same problem again
  • <many>: Only a committer should be able to assign themselves, unless the patch has been committed at which point anyone can assign a committer to keep the historical record intact
  • <many>: the system doesn't require basiscally anything but it seems reasonable to require that, low barrier, add defaults
  • <many>: We should add a parking lot for patches where the author just wants to run it through CI but isn't currently looking for active review. This would keep those patches out of the way when looking for stuff to work on
  • Unknown: Hacking on the websites locally and testing is hard - submitting a postgres patch is hard but submitting a patch to an infra project is magnitudes harder
  • Robert Haas: we need to make the infra projects public in order to scale
  • <many>: The -www list doesn't have enough traffic to get meaningful amount of review performed
  • Peter Eisentraut: how about the process for changing Commitfest app? We need reliable deployment dates where the changes are clearly stated and available on staging systems ahead of time
  • Robert Haas: Release notes are needed, when changes happens there is no way of knowing why or how
• Peter Eisentraut - Are we keeping the cadance of commitfests?
• Robert Haas - Changing it now without changing other things wont help
• Tomas Vondra - The main problem with the Commitfest app is that we have two places with info, the list and the app. It's very easy to forget to update the state, can that perhaps be improved with automation of some sort, like tags in email?
• Christoph Berg: Debian does that by adding control tags to emails recently
• Peter Eisentraut: Well, that was like decades ago..
• Christoph Berg: For debian that is recent
• Robert Haas - A Chatgpt summary of long threads might be helpful as long as it's clearly marked as an AI summary
• Jeff Davis - It would be an interesting experiment
• Robert Haas - In all seriousness, summarizing a large piece of text like a mail thread is admittedly what LLM based systems are good at, maybe we should try that?
• Tomas Vondra - Having the CF app remind authors to update the state would be helpful when a new patch is detected in the thread
• Andrew Dunstan - A new patch version doesn't mean it's automatically in "needs review"
• Heikki Linnakangas - To summarize, we should stop moving patches along wholesale and add a free-form textfield to state blockers

Muiltithreading

• Bruce Momjian - Whats the next topic?
• Peter Eisentraut - Multithreading
• Bruce Momjian - ...oh boy
• Heikki Linnakangas - What has been done so far is groundwork to use threadsafe functions and library calls, moving to reentrant parsers and other infrastructure parts. The Wiki page is kept fairly up to date so I won't go into full details now. Refactoring the postmaster code to reduce numbers of pins is another workstream, lots of refactoring and groundwork has been performed by many people. There no blockers or regressions so far, at worst there is sideways movement only. Up ahead is getting rid of using pids, and getting rid of using signals and filedescriptors etc. There is lots of work do do but fairly straightforward how handle it. For extensions, they need to be able to label themselves threadsafe/not threadsafe/require threadsafety or something. There is a sandbox repo on my Github for anyone wanting to play with it. New items for discussion: global variables must become thread-local, and global variables marked up with labels. A full session struct is appealing as it can aid connection pooling but it can come as a later step. We need to ensure that all tooling we do for this is available to extension authors, and is made easy to use since they will have to go through the same excercise. There is a tool to find global variables made by Tristan, this needs to be a packaged tool for CI as well as extension authors.
• Peter Eisentraut - Labeling global variables seems like the logical next step towards threading
• Heikki Linnakangas - Moving to thread local variables should have no negative impact. We need to change how we define GUCs though since you can't take the address of a thread local variable, both in core and in extensions. Can we use this as a vehicle for a larger rewrite of how we define GUCs if we need to change it anyways?
• Matthis van de Meent - Maybe we can generate the code based on information somewhere instead if hand-coding it?
• Heikki Linnakangas - Should GUCs be backed by variables or by getter/setter functions instead?
• Robert Haas - Changing the semantics should perhaps be done later separately from making GUCs threadlocal to keep things moving

ABI stability

• Peter Eisentraut - It comes up every now and again that we break ABI stabilty, users find it just before release or just after. ABI breaks can also come in a security release which makes it hard to detect ahead of time. A patch has been proposed but it didn't get traction
• Heikki Linnakangas - No objections from me to do something
• Peter Eisentraut - I was hoping that extension authors would show up and say something but it's been silent. The idea of the patchset was to take a dump of the ABI at release, and then run tests of the current ABI against the release baseline. If we do that however, then everyone signs up to maintain that
• Jelte Fennema-Nio - It only needs to be maintained for backpatching
• Peter Eisentraut - ABI is different per platform, so it needs to be per branch and per supported platform
• Matthias van de Meent - Does that work on macOS?
• Peter Eisentraut - The tool is backed by an ELF tool so it work on ELF platforms. Other projects are using similar strategies and tools
• Magnus Hagander - It could be run on the buildfarm which has lots (all) of the platforms
• Heikki Linnakangas - Is this done and supported in-tree or how and where would it work?
• Peter Eisentraut - It could be in the tree, or done separately in the buildfarm
• Christoph Berg - What about the risk of false positives during backpatching, is the expectation that noone needs to do anything?
• Peter Eisentraut - Hopefully noone has to do anything
• Christoph Berg - From a packager perspective it would be great, we currently rely on a promise that no problems or bad stuff will ever happen. Debian does this for libraries at the moment
• Peter Eisentraut - The definition of the ABI is big though, multiple gigabytes
• Alvaro Herrera - We need it per platform, I would prefer to keep it out of tree to avoid increasing the repo size
• Andrew Dunstan - We could make a buildfarm module which connect an out-of-tree tool for building the definition
• <many> - out of tree is preferrable
• Jelte Fennema-Nio - What would be the process for changing things?
• Peter Eisentraut - It should mainly be to add exclusions since the ABI is frozen according to the release baselie
• Heikki Linnakangas - We might add a new function which needs a new baseline

-- Peter Eisentraut - what does it mean to be an ABI

• Heikki Linnakangas - Let's start with an out of tree process to start with, we can always change if we need to
• Christoph Berg - Can it be made smaller by just carrying diffs from previous versions?
• Magnus Hagander - If it's a binary file there are no diffs
• Peter Eisentraut - It's an XML file
• Christoph Berg - ok, so it's binary..
• <many> - To summarize, let's start out of tree and then re-evaluate

Rust in extensions and in core

• Peter Eisentraut - My point with this wasn't that we should use rust in core - but rust is used in many extensions and there is no overlap between core developers and extensions authors using rust. There are no communication points between Rust folks and core C developers, is this a concern? How will threading work with extensions? Tooling we make wont cover rust
• Jeff Davis - I think its a concern, Rust is the best C FFI but it doesnt support our errorhandling etc
• Matthias van de Meent - Rust need better memory semantics
• Jeff Davis - If the allocator API was available it would allow different allocators and potentially support postgres contexts, but it's been unstable for years. Rust is very close but there is still undefined behavior around memory management
• Peter Eisentraut - Sounds like it's not ready
• Jeff Davis - You can make it work and it's probably fine, but it's not really sanctioned by the Rust compiler team. There is no way to define setjmp in Rust. There is a crate out there to handle that but it seems unmaintained these days
• Peter Eisentraut - Installing Rust pulled in 150 packages which wasn't appealing
• Heikki Linnakangas - Thats Rust for you
• Peter Eisentraut - ..and then it was the wrong version and it pulled in 150 more packages
• Devrim Gunduz - Packaging Rust extensions is a nightmare, it needs to download the entire Internet
• Heikki Linnakangas - pgrx pulls down old versions of Postgres and compiles and tests against them which is also taking a long time. pgrx seem to be doing fine on their own but we should get to know them and see if we can help them
• Jeff Davis - The C FFI in Rust is really good, it handles most things but still doesn't handle setjmp/longjmp
• Andrew Dunstan - Which extensions are using Rust?
• Matthias van de Meent - The anonymizer, a uuid extension
• Jelte Fennema-Nio - Timescale is using it for some of their extensions (vectorscale)
• Heikki Linnakangas - The folks that are interested in Rust are generally not interested in C at all so we wont get them to help us, but maybe we can help them
• Peter Eisentraut - How will the multithreading work play with Rust?
• Heikki Linnakangas - It should just work. People are already writing Rust extensions which use threads so I'm not concerned
• Matthias van de Meent - pgrx should not be used for Rust extensions in core, but I wouldn't mind an extension in Rust in core
• Nathan Bossart - What is Linux doing, how are they handling this?
• Matthias van de Meent - I dont know, but I think they have their own Rust standard library
• Heikki Linnakangas - That's still an open discussion in the Linux kernel community, if the underlying C interface is wishy-washy enough to not support making a safe Rust interface
• Peter Eisentraut - Is unsafe expected in Rust or is it sloppy?
• Heikki Linnakangas - When interfacing with postgres it's expected since it's the only way when talking to C code
• Bruce Momjian - Do people actually install hundreds of packages into production?
• Heikki Linnakangas - Ohyes.. compiling a rust project compiles it down to a single big binary, so dependencies are pulled in and there are no dynamic libraries

Mentoring

• Robert Haas - 1:1 mentoring going on, but is a black box for me for the most part. People I mentor are somewhat inactive, I would like to hear more from them. The 1:1 offer was good and well-received but the results have not been great so far. There are monthly hacking sessions on Discord where we are discussing a pre-recorded talk, and these are going great. A group of people show up every time, many of whom are regularly coming back. It might not do a great job bringing new people in but it clearly has value for those attending. It takes a lot of time to organize and prepare for, lots of mechanics that need to happen. Some folks are there to just listen which might not be a bad thing - there has been feedback from folks who were just listening saying they learned a ton from hearing the discussion. The Discord server needs more activity, currently it isn't discoverable which would be great if it was to attract more people. There is a lot more we could be doing as a community to mentor new folks, and there is an appetite for it if we can figure out how to reach interested folks with the right offerings
• Alvaro Herrera - Is discord like iRC?
• Dave Cramer - Think of it more like Slack
• Robert Haas - It behaves a lot like Slack, and since I created this I can set it up in a way that it works for the mentoring, as opposed to the postgres Slack which I have no control over. There is a pgbouncer channel as well requested by Jelte where folks are asking questions etc
• Andrew Dunstan - It terms of the program, I have two mentees, one of them isn't taking full advantage of it (he is setting the schedule himself and meetings are few and far apart), the other one is meeting monthly and making good progress since he is taking good advantage of it. 50% success rate
• Robert Haas - 50% is actually really good. Tomorrows committers will come from todays newcomers
• Unknown - How is the hacking workshop done?
• Robert Haas - I pick a set of talks and poll them, and then decide based on the votes. It might not be the top voted paper but it's good indicator. Then the speaker is contacted to be involved and a signup is created. Mostly it's a Q&A and sometimes it's more involved. The speaker is the expert, not me
• Alvaro Herrera - Are these sessions recorded?
• Robert Haas - No, they are not recorded since it may affect the ability for people to ask questions
• Peter Eisentraut - It's a good place to have low-bar entry to asking questions rather than emailing -hackers which might be daunting for new contributors
• Heikki Linnakangas - Maybe it can promoted better, I didnt even know it existed until recently
• Matthias van de Meent - Maybe the name including "mentor" scares some off thinking the Discord server is just for those in the mentoring program
• Robert Haas - I am happy to hear suggestions
• Magnus Hagander - How does moderation work?
• Robert Haas - It's all done by the server admin, Discord does very little. So far it hasn't been a problem, if it does then I can give more people admin rights to spread the load
• Dave Page - I just signed up and was very pleased to see that I had to agree to the COC
• Alvaro Herrera - Is it a paid service or free?
• Robert Haas - It's free. There are things you can buy but it's not something we need, we don't even use the things which are there now for free
• Heikki Linnakangas - Discord is good for audio calls, have you considered doing office hours?
• Robert Haas - No, not yet, but since there are committers who do that it would be good to publicize so more people learn about it. Typically discord isn't any better than zoom or google meet or other specialized platforms for these types of meetings. It would however be great to publicize the available office hours, we could do a lot more like this
• Peter Eisentraut - How has the office hours been going, how do they work?
• Tomas Vondra - I published and announced that they exist to make it clear for people that they could sign up. Maybe 5 people requested a call and I did have a few of those happen, some started as an email to then become 1:1 calls. Two of those people have since submitted a patch based on the discussions in the office hours. I think it would be good to have a public list somewhere to keep it from being buried on personal blogs or social media
• Peter Eisentraut - So it's always with a single person?
• Tomas Vondra - Yes, it's a private conversation with one person to give that person all the attention, with calls lasting up to 30 minutes

Additional toolchains in the test suite

• Jacob Champion - Who here came to the testing unconference in Canada? <showing of hands> I was agonizing about how to frame this since I have an agenda which I'm not ready to give up on, but I want to make sure that everyone can disagree with this. I do lots of work which cannot be tested well, or at all, with the current test infrastructure, like protocol and authentication/authorization work. I have a preferred alternative myself. If someone like me comes forward and wants to add a new testing framework, thats a big deal, even if a committer doesnt write tests in the system themselves they are still on the hook to fix any bugs revealed by it. What is needed for a committer to pick this up?
• Andrew Dunstan - I think coming up with a usecase is a good start
• Robert Haas - The argument that Andres has brought up is that Perl is pretty dead, and a lot of the modules are pretty dead
• Bruce Momjian - TCL! ..I'm sorry Robert
• Robert Haas - My gut reaction was we need to create parity with what we have in Perl and then we can move on, but that wasn't how Jacob wanted to work
• Andrew Dunstan - We have 75000 lines of code in the Perl tests, we are going to be stuck with that for a while. I think that the next step is to show something we can't do with what we have
• Peter Eisentraut - That was done in Vancouver, what happened with that?
• Jacob Champion - It deadlocked on it needing to replace Perl. I dont think we need to abandon Perl, rather we should focus on adding a new one beside it. I would rather incrementally build something than do a big bang switch
• Jeff Davis - If we dont move away from Perl and add a third test framework, where do we end up after that?
• Nathan Bossart - Every time someone tries to replace a test framework by adding a new one, the result always ends up with having one more framework with the old one remaining, it never works
• Heikki Linnakangas - It's ok to have multiple harnesses as long as there is a consistent way to execute them
• Peter Eisentraut - We have three already
• Heikki Linnakangas - We need one framework/harness to run the tests and collect the results
• Peter Eisentraut - We have meson for that
• Tomas Vondra - As a committer you need to know and interact with all of them, people learned that for the Perl framework, and while it's probably good with specialized tests it's not a zero cost game
• Jeff Davis - Is this a general purpose framework or a specific framework for protocols?
• Jacob Champion - pytest is a general purpose framework, so it's possible for anyone to do more in that, but I've used it for protocol testing for now
• <many> - If we can use Pytest to move away from Perl over a longer period of time then that would be a good idea
• Jacob Champion - We need to avoid the dependencies
• Matthias van de Meent - The main difference with Perl and Python is that Perl can bind with C fairly easily, and in Python you need a library
• Jacob Champion - I use FFI in Python, in addition to a library
• Robert Haas - If we depend on a driver in python then how can you write tests for a new protocol version, the driver doesnt speak that version, we need to use FFI
• Peter Eisentraut - One concern was how pytest is connected to the main buildsystem
• Jeff Davis - Is there a problen with python 2 still
• <many> - no, Python 2 is dead
• Heikki Linnakangas - How we do get started with this, how to bootstrap, do we choose something we have which isn't working well?
• Jacob Champion - Please give suggestions
• <many> - pg_dump!
• Robert Haas - C'mon, let's not set him up for failure!
• Jeff Davis - Do we have any reason to believe parity with the Perl tests would be a problem?
• Jacob Champion - Anything written in the perl tests can most likely be written in Python
• Heikki Linnakangas - Writing new tests with the fault injectors is clunky
• Peter Eisentraut - src/test/ssl could be a good place to start
• Jacob Champion - Agreed, it would be great to get rid of the bespoke certificates there
• Heikki Linnakangas - How does extensions do this
• <many> - Most extensions don't use the existing perl framework so it's not a concern

Additional user mailinglists

• Peter Eisentraut - It was pointed out that -hackers is going up and -general is going down year over year, and people are moving to new channels like Discord, Slack, Telegram, Stack Overflow, Reddit etc. Is this a good experience for users, it's all very fragmented and there are rogue inofficial ones. How do people find where the experienced users are. Traditionally open source projects have a connection between developers and users. We are loosing signals around bugs etc when the information is shared elsewhere. This is a bad experience for the users.
• Dave Page - We cant stop it, every time someone starts something new there will eventually be a postgres channel on it
• Magnus Hagander - We can choose to participate.
• Bruce Momjian - What sense are we not capturing, do we know, is it 20% or 95% or?
• Peter Eisentraut - Compared to 20 years ago we have lost 50% of the traffic
• Tomas Vondra - I did the math for a keynote, and since the peak in 2006 the user lists have lost 60%, this is also true for -bugs
• Christoph Berg - Postgres has gotten so big that people dont see it as a product from a specific project, people take it from granted and ask questions everywhere, We can't get these people back but we can create channels in the forums where they are
• Jelte Fennema-Nio - Github has what we need and most postgres users already use Github
• Robert Haas - Everyone has different preferences and there will be new platforms coming up every two years or more frequent than that
• Dave Page - A lot of people find answers via Google from Stack Overflow and never even ask on any forum, they can read answers already created
• Peter Eisentraut - On the community page on the website we point to iRC and the mailinglist, is that helping our users?
• Dave Page - If we link to it from the site its assumed that the forum follow the COC, and we owe it to our users to only direct them to safe places
• Robert Haas - Thats true, but Stack Overflow is such a vital resource these days
• Magnus Hagander - It is, but do we need to direct people there, don't they find it regardless?
• Robert Haas - Maybe not, but it seems weird not to
• Peter Eisentraut - What is an objective set of criteria for adding it to the website, like the mentoring discord?
• Magnus Hagander - It should be documented who runs it, it should be run by more then one person, and it should be documented to follow the community COC
• Dave Page - Discord is very different way from Stack Overflow, it's a chat system rather than a Q&A forum, how does it handle moderation?
• Robert Haas - Discord doesn't do any moderation but Stack Overflow does moderate and track, so there is different levels of editorial control. Chat services are left to the admin to moderate and monitor whereas the Q&A systems are controlled by the site and company owning the site
• Magnus Hagander - If there was a postgres stack overflow it would be different
• Dave Cramer - There are postgres tags
• Magnus Hagander - We can link to them by separating them by categories, to make it clear that there are differences between community and thirdparty resources
• Magnus Hagander - We should list both types of services, but also run our own discord
• Christoph Berg - So who will add it to the website?
• Dave Page - I can volunteer
• Jelte Fennema-Nio - Why don't we allow issues on Github?
• Andrew Dunstan et.al - Since noone want to commit to monitoring it

What to do at the developers meeting in Canada

• Peter Eisentraut - I am organizing the developer meeting at pgconf.dev in Canada together with Noah, how do people want the developer meeting to be run, should we do it like how we've had this meeting today or should do more group-work etc?
• Dave Page - I like the updates from various groups
• Peter Eisentraut - That's what's the Community Summit is for, I think
• Robert Haas - We can't get all the active developers in a room of this size; and we cant get this type of meeting in a room of the size room which fits all the active developers. The format for today's meeting has been good, but it excludes people which sucks
• Magnus Hagander - Maybe we need to resign to the fact that the developer meeting isnt intended to make decisions
• Peter Eisentraut - One of the fundamanetal decisions we need to make is do we want to have a meeting with 25 people, or a larger meeting where attendees are divided in groups
• Peter Eisentraut - If you have a developer meeting with 50 people in 5 groups, how is that meaningfully different from an unconference?
• Bruce Momjian - The developer meeting in Canada felt more like a reporting meeting
• Robert Haas - I dont like to exclude people who want to be there, but if you are you might as well make it small enough be able to act on decisions.
• Dave Page - Arguably, the developer meeting last year was more of a project meeting than a developers/development meeting
• Peter Eisentraut - Even just inviting major contributors is 50 people which is a lot
• Robert Haas - Traditionally we had the developer meeting to make hard decisions, but we don't really do that anymore. Today was a very different experience but it was more a way to get advice and opinions on topics they care about
• Peter Eisentraut - Should we perhaps do this in Canada?
• Nathan Bossart - I think this size meeting is invaluable for getting in-depth discussions on topics
• Jelte Fennema-Nio - If you make smaller groups where only those interested in the topic attend are then groups are very narrow as opposed to this meeting
• Magnus Hagander - Single-topic groups has the risk that people get assigned to groups which weren't their primary choice and they miss the ones they want to attend
• Dave Page - Historically the meeting was focused on discussing deep technical topics
• Robert Haas - Some of those discussions weren't very good, some were but some weren't