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-24 00:59:14
Message-ID: 4B5B9B62.30604@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> 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.
>>
>
> I think you're kind of caricaturing what I said here, and what Kevin
> said. People really are willing to put time into helping get a
> release out the door if they feel like their efforts will move the
> needle. Do they get directly paid to make the release happen faster?
> No, probably not. That doesn't mean they won't put time into it. I
> don't think too many people get paid to do patch review either, but
> somehow we manage to have CommitFests. It's not magic, but it does
> help.
>
>
>

Certainly I was being slightly facetious. If anyone is surpised they
haven't been paying attention ;-)

But the point I'm trying to get across is that an assumption that better
process and more organization is somehow going to get us to a shorter
period between feature freeze and release is not necessarily so. See
Tom's response upthread for more reasons why this is so. That's not
meant to discourage people from doing work, it's meant to stop people
from getting unreal expectations.

And, BTW, more process and organization can itself consume scarce
resources as well as annoying some of the people you want to do some of
this work. There is a sweet spot that we need to aim at.

OK, back to making the buildfarm client git-aware ...

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brook Milligan 2010-01-24 01:00:51 handling contrib directories as modules not shared libraries
Previous Message Bruce Momjian 2010-01-24 00:48:55 Re: commit fests