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

From Simon Riggs
Subject Re: The purpose of the core team
Date
Msg-id CANP8+j+dcsb+fSgFaMicdvvt1igfKODS+oDSu1sS5Uk7z-tpqA@mail.gmail.com
Whole thread Raw
In response to Re: The purpose of the core team  (Noah Misch <noah@leadboat.com>)
Responses Re: The purpose of the core team  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 12 June 2015 at 06:48, Noah Misch <noah@leadboat.com> wrote:
On Thu, Jun 11, 2015 at 03:47:06PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >         http://www.postgresql.org/developer/core/

> After going over this a few times, there is one thing that strikes me
> that nobody has mentioned: the list of tasks mentioned there has one
> that's completely unlike the others.  These are related to human
> relations:
>
>     Acting as a conduit for confidential communication.
>     Making policy announcements.
>     Managing permissions for commits, infrastructure, etc.
>     Handling disciplinary issues.
>     Making difficult decisions when consensus is lacking.
>
> while this one is highly technical:
>     Coordinating release activities.

Quite so.  Deciding "it's time for a release" requires the same knowledge and
skills as deciding "it's time to commit patch P", yet we have a special-case
decision procedure.  A release does require people acting in concert for a
span of a few days, but that precise scheduling is work for an administrative
assistant, not work befitting -core.

Deciding "WHAT goes in the next release?" is what Committers do, by definition.

It seems strange to have a different mailing list for "WHEN is the next release needed?", so those two things should be combined.
 
> It seems that only this last one is where most people seem to have a
> problem.  I wonder if it makes sense to create a separate group that
> handles release activites -- the "release team."

I think the decision to initiate or revoke release scheduling belongs in the
same forum as patch development, usually -hackers or -security.  We'd need to
pick a way to clearly signal the discussion's conclusion, analogous to how a
pushed commit unambiguously disposes a patch proposal.  The balance of
coordinating release activities is mechanical, and -packagers seems adequate
for it.

Packagers should be about "HOW do we make the next release", which is separate from the above.

Ultimately, "How" effects "When", but "When is it needed?" is an earlier thought.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Reconsidering the behavior of ALTER COLUMN TYPE
Next
From: Simon Riggs
Date:
Subject: Re: Is it possible to have a "fast-write" Index?