Re: The purpose of the core team - Mailing list pgsql-hackers

On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian <bruce@momjian.us> wrote:
> There has been some confusion by old and new community members about the
> purpose of the core team, and this lack of understanding has caused some
> avoidable problems.  Therefore, the core team has written a core charter
> and published it on our website:
>
>         http://www.postgresql.org/developer/core/
>
> Hopefully this will be helpful to people.

I believe the core team is suffering from a lack of members who are
involved in writing, reviewing, and committing patches.  Those things
are not core functions of the core team, as that charter illustrates.
However, the core team needs to know when it should initiate a
release, and to do that it needs to understand the impact of bugs that
have been fixed and bugs that have not been fixed.  The recent
discussion of multixacts seems to indicate that the number of core
team members who had a clear understanding of the issues was zero,
which I view as unfortunate.  The core team also needs to make good
decisions about who should be made a committer, and the people who are
doing reviews and commits of other people's patches are in the best
position to have an informed opinion on that topic.

As a non-core team member, I find it quite frustrating that getting a
release triggered requires emailing a closed mailing list.  I am not a
party to all of the discussion on my request, and the other people who
might know whether my request is technically sound or not are not
party to that discussion either.  I disagreed with the decision to
stamp 9.4.3 without waiting for
b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't
comment on it, because it was decided in a forum in which I don't get
to participate, on a thread on which I was not copied.  I realize
that, because decisions about whether to release and when to release
often touch on security issues, not all of this discussion can be
carried on in public.  But when the cone of secrecy is drawn in so
tightly that excludes everyone who actually understands the technical
issues related to the proposed release, we have lost our way, and do
our users a disservice.

I am not sure whether the solution to this problem is to add more
people to the core team, or whether the solution is to move release
timing decisions and committer selection out of the core team to some
newly-created group.  But I believe that change is needed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company