Re: Last gasp

All,

From my observation, the CF process ... in fact, all development processes we've had in Postgres ... have suffered from only one problem: lack of consensus on how the process should work. For example, we've *never* had consensus around the criteria for kicking a patch out of a commitfest. This lack of consensus has resulted in disorganization, ennui towards the process, deadline overruns, and a lot of general unhappiness. People have stopped believing in the CF system because we'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 willing to set aside individual differences of opinion on what the criteria should be (especially when it comes to the patches we 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 CF on -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
* judged as 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 they are.

We also need better tools for the CF, but frankly better tools is a minor issue and easily solved if we have a consensus which 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 the PostgreSQL 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