Re: Formatting Curmudgeons WAS: MMAP Buffers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Formatting Curmudgeons WAS: MMAP Buffers
Date
Msg-id BANLkTim+asWGq3BtC7nkNXm3wugXH-XdLg@mail.gmail.com
Whole thread Raw
In response to Re: Formatting Curmudgeons WAS: MMAP Buffers  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Formatting Curmudgeons WAS: MMAP Buffers  (Josh Berkus <josh@agliodbs.com>)
Re: Formatting Curmudgeons WAS: MMAP Buffers  (Greg Stark <gsstark@mit.edu>)
Re: Formatting Curmudgeons WAS: MMAP Buffers  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Mon, May 9, 2011 at 1:53 PM, Josh Berkus <josh@agliodbs.com> wrote:
> While the first was specific to the Aster submissions, I've seen the
> second problem with lots of first-time submissions to this list.  Our
> feedback to submitters of big patches requires a lot of comprehension of
> project personalities and politics to make any sense of.

Ah ha!  Now we're getting somewhere.  As was doubtless obvious from my
previous responses, I don't agree that the process is as broken as I
felt you were suggesting, and I think we've made a lot of
improvements.  However, I am in complete agreement with you on this
point.  Unfortunately, people often come into our community with
incorrect assumptions about how it works, including:

- someone's in charge
- there's one right answer
- it's our job to fix your problem

Now if you read a few hundred emails (which is not that much calendar
time, if you read them all) it's not too hard to figure out what the
real dynamic is, and I think that real dynamic is increasingly
positive (with some unfortunate exceptions).  But if the first thing
you do is post (no doubt about some large or controversial change),
yeah, serious culture shock.

>>> That goes double for some of the people complaining in this thread about
>>> dissatisfaction with the current process.
>
> The problem is not the process itself, but that there is little
> documentation of that process, and that much of that documentation does
> not match the defacto process.  Obviously, the onus is on me as much as
> anyone else to fix this.

I can't disagree with this, either.  I'm not sure where it would be
possible for us to document this that people would actually see and
read, and I think it's a tough to understand just from reading a wiki
page or a blog post: if you've never been part of a community that
operates this way, then it's kind of strange and it takes a while to
adjust.  Of course from the inside it seems to make a fair amount of
sense, but what good is that?  Anyhow, whatever we can do to help
people get into the swing of things I'm highly in favor of.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: fsync reliability
Next
From: Robert Haas
Date:
Subject: Re: Why not install pgstattuple by default?