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

From Joshua D. Drake
Subject Re: The purpose of the core team
Date
Msg-id 5579B753.7000006@commandprompt.com
Whole thread Raw
In response to Re: The purpose of the core team  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: The purpose of the core team  (Andrew Dunstan <andrew@dunslane.net>)
Re: The purpose of the core team  (Magnus Hagander <magnus@hagander.net>)
Re: The purpose of the core team  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 06/11/2015 07:12 AM, Robert Haas wrote:
>
>> 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.

Bruce: Committer, maintains pg_upgrade and reviews patches here and there.

Magnus: Committer, primary Windows dude and reviews patches here and there.

Peter: Committer, reviews patches not only on -hackers but also -docs

Tom: Enough said

Dave: Committer, agreed that he doesn't do much -hackers work but I 
guarantee you he provides a unique perspective to the rest of his group 
due to his management of PgAdmin and an entire team at EDB.

JoshB: Advocacy. There is a strong argument that does not need to be a 
core position.

In short, I don't agree with you.


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

True but that isn't the fault of core outside of communication. The 
hackers, reviewers and committers of those patches should be required to 
communicate with core in a way that expresses the true severity of a 
situation so core can make a:

Management decision.


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

Which happens.

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

Nor should you be. This idea that all communications must be open is a 
joke and shows a lack of maturity in a community. There are things that 
must be discussed in private for many reasons.

Now, if you are saying that core isn't reaching out directly to people 
involved in suspect work to make a quality decision that may be one 
thing but I also know that happens.

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

We do not all have to agree and further there is nothing stopping you 
from commenting on -hackers. If enough people agree with you, core is 
going to listen.

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

We can't lose our way when this is the way it has always been.

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

If you have a people problem and you add people, you only have a bigger 
people problem. In terms of timing and committer selection, core does a 
very good job. Core has been around longer than you have and has shown 
great respect, maturity and management skills with most (not all of 
course) aspects of this community.

There is one change to core that I (and I know others) would like to see:

They should be serve a finite term and be elected.

Sincerely,

JD



-- 
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 9.5 release notes
Next
From: Robert Haas
Date:
Subject: Re: The purpose of the core team