About PostgreSQL Core Team - Mailing list pgsql-hackers

From adherent postgres
Subject About PostgreSQL Core Team
Date
Msg-id SEYPR01MB4582A5187CA6863A555843DF8ED19@SEYPR01MB4582.apcprd01.prod.exchangelabs.com
Whole thread Raw
Responses Re: About PostgreSQL Core Team
Re: About PostgreSQL Core Team
List pgsql-hackers
Hi hackers:
    I came across a blog that I was very impressed with, especially the views mentioned in it about PostgreSQL Core Team,Especially tom_lane in PostgreSQL Core Team,The new features submitted by some developers are often tainted with personal preferences, but fortunately not some new features do not lose the opportunity to be merged because of their personal preferences, This is blog url:https://www.percona.com/blog/why-postgresql-needs-transparent-database-encryption-tde/


```

While I believe Transparent Database Encryption in PostgreSQL is important, I think it is just an illustration of a bigger question.  Is technical governance in PostgreSQL designed to maximize its success in the future, or is it more about sticking to the approaches that helped PostgreSQL reach current success levels? For a project of such scale and influence, there seems to be surprisingly little user impact on PostgreSQL Governance. The PostgreSQL Core Team consists of “seven long-time community members with various specializations” rather than having clear electable positions, as many other open source organizations do.  The development process in PostgreSQL is based around a mailing list rather than more modern and organized issue tracking and pull-request-based development workflows.   Interested in PostgreSQL Bugs? There is no bugs database that allows you to easily see which bug is confirmed and what version it was fixed in a user-friendly way. Instead, you need to dig through the bugs mailing list.
```


Attachment

pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: John Naylor
Date:
Subject: Re: Can we do something to help stop users mistakenly using force_parallel_mode?