Re: commit fests

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: commit fests
Date: 2010-01-23 17:07:47
Message-ID: 4B5B2CE3.4030004@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
>> Perhaps it isn't that five months is outrageous,
>> but that it doesn't really benefit from an unorganized swarm of
>> activity by all the developers, and we've not worked out a
>> reasonable framework for who should do what during that time to best
>> benefit the project while giving all these volunteer and sponsored
>> developers something they are willing to put effort into.
>>
>
> I think that's pretty close.
>
>
>

I think it's pretty close to 100% BS. Who constitutes this legion of
sponsored developers in desperate need of organization? And what are
they sponsored for? I can't speak for others, but with one exception the
only sponsorship I have received is for actual development work, not
release finishing (and the exception ended up being mostly development
anyway). Sponsors almost always want to provide money for actual
features. And as for volunteers, they have a fantastic resistance to
being organized in some prescriptive way. We need to achieve what we can
by persuasion. It's sometimes a pain in the neck, but it's the reality.

The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can
just throw bodies at ("Nine women can't make a baby in a month.").
Sadly, some things do just take time to work out. It's frustrating, but
shortening the time could simply result in our making less polished
releases. The problem is likely to grow with our increasing emphasis on
enterprise level features. But I don't think that sacrificing quality
for timeliness is a good trade.

That is not to say that we can't make some improvements in process, but
expecting them magically to solve this problem is a bit cargo cultish.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-01-23 17:09:05 tab completion for prepared transactions?
Previous Message Simon Riggs 2010-01-23 16:42:16 Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.