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
Re: The purpose of the core team Re: The purpose of the core team |
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: