All,
From my observation, the CF process ... in fact, all development processes we've had in Postgres ... have suffered from
onlyone problem: lack of consensus on how the process should work. For example, we've *never* had consensus around the
criteriafor kicking a patch out of a commitfest. This lack of consensus has resulted in disorganization, ennui towards
theprocess, deadline overruns, and a lot of general unhappiness. People have stopped believing in the CF system
becausewe've stopped running it.
I'm encouraged at this point that we've seen where this lack of consensus can lead us, maybe at this point we're
willingto set aside individual differences of opinion on what the criteria should be (especially when it comes to the
patcheswe each individually care about) in service of a smoother-running process. Some suggestions:
- for the first 2 weeks of each CF, there should be a *total* moritorium on discussing any features not in the current
CFon -hackers.
- the CF manager should have unquestioned authority to kick patches. As in, no arguing.
- we should have simple rules for the CF manager for kicking patches, as in: * no response from author in 5 days *
judgedas needing substantial work by reviewer * feature needs spec discussion
However, the real criteria don't matter as much as coming up with a set of criteria we're all willing to obey, whatever
theyare.
We also need better tools for the CF, but frankly better tools is a minor issue and easily solved if we have a
consensuswhich people are willing to obey. For that matter, if we have a smooth and impartial process, we can do other
things,including: training new reviewers, promoting new committers, changing the length of the CF cycle, or changing
thePostgreSQL release cycle (yes, really). While our review and commit process is completely subjective and
inconsistent,though, we can't do any of these things.
--Josh Berkus
