Re: CF3+4 (was Re: Parallel query execution)

On Tue, Jan 22, 2013 at 1:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, and a lot more fairly-new developers who don't understand all the
> connections in the existing system.  Let me just push back a bit here:
> based on the amount of time I've had to spend fixing bugs over the past
> five months, 9.2 was our worst release ever.  I don't like that trend,
> and I don't want to see it continued because we get laxer about
> accepting patches.  IMO we are probably too lax already.

Really?  Hmm, that's not good.  I seem to recall 8.4.x being pretty
bad, and some of the recent bugs we fixed were actually 9.1.x problems
that slipped through the cracks.

> For a very long time we've tried to encourage people to submit rough
> ideas to pgsql-hackers for discussion *before* they start coding.
> The point of that is to weed out, or fix if possible, (some of) the bad
> ideas before a lot of effort has gotten expended on them.  It seems
> though that less and less of that is actually happening, so I wonder
> whether the commitfest process is encouraging inefficiency by making
> people think they should start a discussion with a mostly-complete
> patch.  Or maybe CF review is just crowding out any serious discussion
> of rough ideas.  There was some discussion at the last dev meeting of
> creating a "design review" process within commitfests, but nothing got
> done about it ...

I think there's been something of a professionalization of PostgreSQL
development over the last few years.   More and more people are able
to get paid to work on PostgreSQL as part or in a few cases all of
their job.  This trend includes me, but also a lot of other people.
There are certainly good things about this, but I think it increases
the pressure to get patches committed.  If you are developing a patch
on your own time and it doesn't go in, it may be annoying but that's
about it.  If you're getting paid to get that patch committed and it
doesn't go in, either your boss cares or your customer cares, or both,
so now you have a bigger problem.  Of course, this isn't always true:
I don't know everyone's employment arrangements, but there are some
people who are paid to work on PostgreSQL with no real specific
agenda, just a thought of generally contributing to the community.
However, I believe this to be less common than an arrangement
involving specific deliverables.

Whatever the arrangement, jobs where you get to work on PostgreSQL as
part of your employment mean that you can get more stuff done.
Whatever you can get done during work time plus any nonwork time you
care to contribute will be more than what you could get done in the
latter time alone.  And I think we're seeing that, too.  That then
puts more pressure on the people who need to do reviews and commits,
because there's just more stuff to look at, and you know, a lot of it
is really good stuff.  A lot of it has big problems, too, but we could
be doing a lot worse.  Nonwithstanding, it's a lot of work, and the
number of people who know the system well enough to review the really
difficult patches is growing, but not as fast as the number of people
who have time to write them.

For all of that, I'm not sure that people failing to seek consensus
before coding is really so much of a problem as you seem to think.  A
lot of the major efforts underway for this release have been discussed
extensively on multiple threads.  The fact that some of those ideas
may be less than half-baked at this point may in some cases be the
submitter's fault, but there also cases where it's just that they
haven't got enough looking-at from the people who know enough to
evaluate them in detail, and perhaps some cases that are really
nobody's fault: nothing in life is going to be perfect all the time no
matter how hard everyone tries.

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