Re: The purpose of the core team

On Thu, Jun 11, 2015 at 3:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian <bruce(at)momjian(dot)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.

Yes, and we have recently been discussing how best to solicit those
opinions this year.

> As a non-core team member, I find it quite frustrating that getting a
> release triggered requires emailing a closed mailing list.

It does not, unless you're talking about a security release. You might
have to prod people if they overlook an email on -hackers, but you can
certainly suggest releasing updates there.

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

All of the technical discussion was done outside -core, in lists on
which you are a member. We simply discussed the possible impacts of
scheduling constraints given our personal availability to deal with
the release process, and the possible PR impact of waiting. Even then
I think there were all of maybe half a dozen short comments on the
thread.

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

Timing *decisions* are not made by -core, as I've told you in the
past. They are made by the packagers who do the actual work, based on
suggestions from -core.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company