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

On Mon, Apr 18, 2011 at 9:50 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Robert,
>
>> 1. We realize we have been too trigger-happy sometimes.
>> 2. But we really want you to participate.
>> 3. And we are trying very hard to do better.
>> 4. And please tell us if we screw up, so we can keep working on it.
>
> I received a private offlist email from someone who didn't feel
> comfortable bringing up their issues with this list publicly.  Let me
> quote from it, because I think it pins part of the issue:
>
> "I believe this is due to the current postgresql "commitfest" process
> whereby there is no real way to present new ideas or technologies
> without coming to the table with a fully-baked plan and patch. This is
> obvious even in the name "commitfest" since the expectation is that
> every patch presented is considered ready-to-commit by the patch
> presenter. This makes a novice or experimental contribution less likely."
>
> You'll notice that this has been a complaint of veteran contributors as
> well; WIP patches either get no review, or get reviewed as if they were
> expected to be committable.
>
> The person who e-mailed me suggests some form of PostgreSQL Incubator as
> a solution.   I'm not sure about that, but it does seem to me that we
> need somewhere or some way that people can submit patches, ideas, git
> forks, etc., for discussion without that discussion needing to
> immediately move to the cleanliness/maintainability/supportable status
> of the patch.
>
> I'm concerned though that if these WIP projects don't get to -hackers,
> then their creators won't get the feedback they really need.
>
> Thoughts?

I think the quality of review that WIP patches get depends very much
on how specific the submitter is about what they'd like to get out of
the process.  If you submit a patch and say "I have this cool patch
that allows FTL travel, but it's WIP, please review" then you're
basically asking some poor schmuck to reverse engineer what the patch
is doing, and, when they find problems with it, guess which of those
problems were things that you didn't think of and which were things
that you knew about but haven't gotten around to fixing yet because
you're still working on it.  This is a pretty thankless task for the
reviewer, and it's not surprising that it doesn't go well.  However,
if you say "I have this cool patch that allows FTL travel.  It current
plays havoc with the transporter beams and the dilithium crystals tend
to shatter if you exceed Warp 3, but I'd like to get a check as to
whether the basic design is sound, and if anyone can see why the
Heisenburg compensator is destabilizing, please let me know", your
chances of getting some useful feedback are pretty good.  Sometimes it
even provokes a rather competitive spot-the-bug race...

Also, I think the reason why we have a process called CommitFest and
not a process called BrainstormingFest is because, when we didn't have
a CommitFest process, patches fell on the floor.  Since we've added
that process, that problem has largely gone away.  But it is generally
not difficult to get a review of a "big idea" for which no code has
been written yet - in fact it's often much faster and easier than
getting a patch reviewed.  It's true that there have been occasional
times when people have gotten lightly toasted for bringing up big new
ideas in the middle of a CF or beta period, but I think we've gotten
less pedantic about that.  Certainly, there are no shortage of ideas
that have been proposed and commented on over the last few weeks, even
as we have been working to get 9.1beta1 out the door.  Code is not
really getting reviewed right now, but ideas *are*.  I'm not going to
claim that this works perfectly: the way that ideas are presented and
the relative level of interest and/or exhaustion of the people
responding certainly play a role, but it is a pretty rare for an email
to -hackers to get no answer at all.  Maybe we need some formal
process here just to make people more comfortable, but it's not
necessary from a workflow perspective.

Thinking back over the kinds of things that have lead to people
getting jumped on, I think I can identify a pattern: people tend to
get jumped on when they allege that our code sucks, or that they're
smarter than we are.  Whether or not they actually meant to imply
those things turns out not to matter - it rubs people the wrong way,
and everyone's a volunteer, so when you rub them the wrong way, they
get annoyed.  I make an effort, as I think most of us do, to be aware
that just because someone makes an annoying remark doesn't necessarily
mean that they are an annoying person; it just means they haven't
quite figured it all out yet.  But there are still people who get
flamed that way far more than they probably deserve.  That's an area
we can improve, but in the meantime, approaching the topic with a bit
of humility goes a long way.  I can't remember the last time someone
said "I was thinking about working on ... and I thought I might
approach it by ... Does this seem like a good idea?  Is it likely to
be too hard for me to tackle?  My skillset is ..." and got flamed for
it.  Some people here (myself included) get a bit pricklier than we
probably ought to from time to time, but everyone is well-meaning and
sincerely wants to help.  The list of users who have had Tom fix a bug
for them within hours of posting a question is not short, and the list
of people who have spent time and energy helping newcomers get started
with PostgreSQL tuning, hacking, or whatever is very long.

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