On Wed, 2011-04-20 at 12:21 -0400, Tom Lane wrote:
> Well, I absolutely think that we need to encourage people to get
> feedback at the design and prototype stages. The problem with the
> commitfest mechanism for that is that when you are trying to work out
> a patch, you don't want to wait around for a couple months for
> comments. The time delay that's built into the CF process means that
> it's fundamentally not very good for anything except finished patches
> that can sit on a shelf for awhile before they get applied.
>
> I think that ideally, WIP reviews would be something that happens
> quickly on pgsql-hackers, and probably it would be best if they were
> explicitly *not* encouraged while a CF is on. I know that I tend to
> see discussions of unfinished patches as something of a distraction
> when I'm up to my ears in committing finished ones, and certainly
> there's less mental bandwidth available then.
We'll the current process certainly places a lot of emphasis on the
"finishing" part. You have commit fests that nominally account for 50%
of development time, and then beta, RC, limbo, backbranch releases -- I
blogged about this a while ago, if you follow all these guidelines and
encouragements, you are left with all of about 20 days per year for
discussion, collaborative planning and coding. Which is obviously
silly, which is why the process breaks down. People do other things as
commit fests fade out, but they subconsciously fear they will get the
stink for it, so public discussion and planning is effectively stifled.
I think we should put less temporal emphasis on the finishing part, but
use the time better. I would imagine one commit fest per month, but
it's only a week long. Then everyone can really concentrate on the
commit fest, people get faster feedback, but there is ultimately more
time to do other things. Something to think about.